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ABSTRACT 


Building  software  systems  from  reusable  software  components  has  been  a  goal 
of  software  engineers  for  nearly  three  decades.  Despite  progress,  the  realization  of 
this  goal  remains  surprisingly  elusive.  Expensive  hardware  systems  such  as  aircraft, 
communication  networks,  and  factory  assembly  lines  are  designed  so  that  various' 
subsystems  (both  hardware  and  software)  can  be  removed  and  replaced  in  order  to 
change  the  performance  and  functionality  of  the  overall  system.  In  a  similar  manner, 
it  should  be  possible  to  change  the  behavior  of  a  component-based  software  system 
in  useful  and  predictable  ways  by  removing  and  replacing  entire  components. 

In  order  to  perform  component-level  maintenance,  an  engineer  must  understand 
not  only  the  structural  relationships  but  also  the  behavioral  relationships  among  the 
component  to  be  replaced,  the  system,  and  the  replacement  component.  These  behav¬ 
ioral  relationships  need  to  be  clearly  documented  and  available  to  engineers  developing 
and  maintaining  component-based  systems. 

This  dissertation  presents  a  small  set  of  precisely  defined  relationships  that  con¬ 
cisely  express  behavioral  relationships  between  software  components.  These  rela¬ 
tionships  may  be  used  to  provide  implementers  and  maintainers  with  useful  infor¬ 
mation  about  how  components  can  and  should  be  composed  when  integrated  into 
component-based  systems.  Furthermore,  these  relationships  encourage  strict  adher¬ 
ence  to  the  well-established  software  engineering  principles  of  modularity,  information 
hiding,  polymorphism,  and  extendibility. 

The  relationships  described  are  language-independent  and  may  be  encoded  in  a 
variety  of  w'ays  using  modern  programming  languages.  The  dissertation  describes 
how  interface-only  components,  templates,  inheritance,  and  other  language  mecha¬ 
nisms  may  be  used  to  encode  these  relationships.  Specific  examples  are  provided  in 
RESOLVE/ Ada95,  a  component-based  software  engineering  discipline  that  uses  Ada 
as  an  implementation  language. 
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CHAPTER  1 


INTRODUCTION 


Building  software  systems  from  reusable  software  components  has  been  a  goal  of 
software  engineers  for  nearly  three  decades.  At  the  1968  NATO  Conference  On  Soft¬ 
ware  Engineering,  M.  D.  Mcllroy  proposed  a  software  components  industry  [McI76]. 
Software  components  with  well  defined  interfaces  would  be  built  and  then  reused  in 
various  software  systems  just  as  hardware  components  with  standardized  interfaces 
are  used  to  construct  physical  systems.  Despite  definite  progress,  the  realization  of 
this  goal  remains  surprisingly  elusive  [Tra95]. 

The  motivation  for  component-based  software  engineering  is  even  more  compelling 
today  than  in  the  past.  Today’s  software  systems  are  extremely  large  and  complex, 
requiring  long  and  costly  development  efforts.  Developing  new  systems,  in  large  part 
by  integrating  existing  software  components  (as  opposed  to  building  a  system  from 
scratch),  clearly  offers  the  potential  to  reduce  system  development  time  and  expense. 
Furthermore,  well  designed  component-based  systems  should  be  easier  to  maintain  if 
software  engineers  are  able  to  perform  some  maintenance  tasks  at  the  component-level 
rather  than  modifying  individual  lines  of  code. 

Expensive  hardw'are  systems  such  as  aircraft,  communication  networks,  and  fac¬ 
tory  assembly  lines  are  designed  so  that  various  subsystems  (both  hardware  and 
software)  can  be  removed  and  replaced  in  order  to  change  the  performance  and  func¬ 
tionality  of  the  overall  system.  Similarly,  it  should  be  possible  to  change  the  behavior 
of  a  component-based  software  system  in  useful  and  predictable  ways  by  replacing 
some  of  the  system’s  components  with  other  components.  If  appropriate  replacement 
components  already  exist,  then  the  benefit  of  this  approach  is  obvious.  However, 
even  if  new  components  need  to  be  developed,  a  sj'-stematic  design  and  implemen¬ 
tation  approach  that  supports  the  ability  to  substitute  a  new  component  for  an  old 
one  without  making  other  changes  to  the  system  offers  advantages  over  the  ad  hoc 
alternatives. 


1 


1.1  The  Problem 


I  he  ".('nfM'iil  prnhh’in  tliis  woi  k  (uldrcssr's  is  tlic  diflicult  ly  of  (h'siyiiing  mid  impli'- 
incntinn ;c()ni])on('nt-l)ascd  systi'ins  that  support  coinixuiciit-lcvi'l  niainti'iianci'.  While 
other  ('iiuinei'i'int;  disei|)liiies  siieeessfiilly  apjily  the  eonipoiieiit-hased  aiijiroaeli  to 
hiiildiiii:  and  iiiaintainiii,y  physical  systems,  it  has  proven  much  iiiort' diflicult  to  ap])ly 
in  software  enyineerin,y.  A  primary  reason  for  this  difliculty  is  that  distinct  software 
comixinents  teixl  to  lx-  more  tightly  coupled  with  each  other  than  most  well-designed 
physical  com])onents.  hurt hermore.  softwan'  components  art'  oftt'u  designed  with  ex¬ 
tremely  suhtle  dependtuicies  that  are  not  ('xplicitly  described.  Thes(>  (h'liendencies 
may  significantly  complicate  reasoning  about  program  Ix'havior  [\\  H92]. 


1.1.1  Component  Dependency  Relationships 

In  curri'iit  software  de\'('lopiiH'nt  practice,  most  software  comjioiu'nts  aix'  (h'signed 
to  serve  a  s])ecific  inirjiosi'  within  the  context  of  a  s|)ecific  softwan'  systi'in.  .\s  a  n’sulf . 
a  comjioiK'iit'  may  depend  on  other  components  used  in  a  specific  system.  \\'h('n 
i>olat(>d  fioiii  the  context  of  a  spc'cific  system,  a  w('ll-d(‘signed  compoiK'iit  still  may 
necf!  to  de])eixl  on  other  compoiH'iits  to  achie\‘('  its  pur]x)se.  W  Ih'Ii  oik'  component 
depeixis  on  another  specific  component  as  a  result  of  its  (h'sign.  w('  n'h'r  to  this  type 
of  relationship  as  a  ilrsifin  di ix  iitlciirn  or  say  that  oix'  component  is  roiipicd  hi/  dcsiqn 
to  another. 

-Minimi/ing  design  d('])endenci('.s  (com])onent  cou])ling)  has  Ix'i'ii  recogni/('d  as  a 
])riniary  goal  in  softwan-  engiiu'ering  since  tlx-  early  197()‘s  [SMCT4].  By  minimix- 
ine  a  com])onent  s  dept-ixh-ncies  on  other  components,  we  makt-  a  compont-nt  t-asier 
to  understand,  t-asier  to  n-ason  about,  and  t-tisit-r  to  rt-use  in  a  varit-ty  of  contt-xts. 
for  tlx-st-  rt-asons.  minimi/ing  dt-sign  dt-pt-ndt-ncit-s  is  tin  important  pit-rt-titiisitt-  for 
successful  com])oTX'nt-h'V('l  m;iint  t-nanct-. 

\\  Ix-n  integratf'd  into  a  software-  system,  a  comixuient  must  lx-  linkt-d  to  otlit-r 
ctimiiont-nts  in  tluit  .system  in  ordt-r  to  st-rve  its  purpose'.  'J'he  final  bintling  of  eint- 
comptiiient  s  eepe-rations  tee  another  ceunpeene-nt 's  eipe-nit ions  may  take-  place-  staticallv 
when  parts  of  the  syste-m  are-  compile-el  etr  whe-n  pre'-ce)m])il('tl  mexliile-s  are-  linke-d. 
-Mternatively.  euie  comieexie-nt 's  e)])t-rat iexis  may  be  bound  It)  the-  etperat ieens  of  anettht-r 
ceimieonent  tlynamically.  at  run  time-.  We-  refer  ft)  the-  tlepe-ixlt-ncies  that  arise  from 
integration  tif  com])e)nr'nts  intt)  a  spt-cific  syste-m  as  inlii/nifimi  di  jiftidcncics. 

( tne-  way  te)  unele-rst anel  the-  difle-re-nce-  be-twe-e-n  th-sign  de-itt-nelt-ncie-s  anel  inte-gra- 
tion  tfejeeiiflencies  is  lee  ceensielt-r  a  librtny  eef  re-usable-  software  cetmiteenents.  .-Ml  de-- 
pe-ixlencie-s  h/firicii  intli\'iehial  ceeinjeetix-nts  in  the-  library  are-  df-sign  dt'j)t'iKle'ucit's 
elepenelencies  which,  in  ge-neral.  sht)ultl  be  minimize-el  fter  the-  n-asons  cite-d  abeeve. 

Hi!i(  ('fi  >1 1  li .  we  will  often  use  the  tei'iii  'e')  )nij)()ix-nt  in  ))l;ice  e)f  ".software'  ('oni])ont'nt  wlie-re  it 
i'  ele  e.r  from  conte'xt  that  the  eoniitone'nt  in  (iix'stion  is  ;i  software  cejinjattient . 
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However,  an  individual  component  in  the  library  may  be  built  from  many  other  com¬ 
ponents  in  the  library.  The  dependencies  between  the  sub-components  composed 
together  within  a  single  library  component  are  integration  dependencies.  In  this  case 
we  can  view  a  single,  perhaps  complex,  component  as  a  component-based  system. 
Assuming  a  component  and  its  sub-components  are  well-designed,  there  is  no  reason 
that  the  integration  dependencies  need  to  be  minimized.  In  a  well-designed  system, 
the  integration  dependencies  are  just  those  dependencies  necessary  to  construct  the 
system. 


1.1.2  Component  Behavior 

The  reason  for  distinguishing  between  design  dependencies  and  integration  de¬ 
pendencies  has  to  do  with  reasoning  about  the  behavior  exhibited  by  execution  of 
component-based  systems.  For  component-based  maintenance  of  software  to  be  vi¬ 
able,  software  engineers  must  be  able  to  reason  about  how  the  behavior  of  a  system 
changes  when  one  component  is  substituted  for  another.  That  is,  a  maintainer  of  a 
component-based  system  needs  to  be  able  to  determine  whether  substituting  a  new 
component  for  an  old  one  will  produce  desired  changes  in  system  behavior  without 
producing  undesired  changes.  Reasoning  about  the  behavior  of  a  component-based 
system  requires  an  understanding  of  the  behavior  of  the  system’s  components  and 
how  they  are  integrated  together  to  form  the  system.  However,  if  components  are 
designed,  implemented,  and  integrated  into  systems  carefully,  it  is  possible  to  reason 
in  advance  about  some  aspects  of  the  post-integration  behavior. 

Software  components  that  support  reasoning  about  certain  specified  aspects  of 
behavior,  independent  of  the  specific  system  into  which  they  are  integrated,  are  said 
to  support  modular  reasoning,  and  potentially,  modular  verification  of  correctness 
[SW94,  DL96,  SG95,  EH094,  EHM091,  WH92].  Modular  verification  is  the  process 
of  formally  justifying  that  the  execution  of  a  software  component  will  exhibit  certain 
specified  properties  when  integrated  into  any  system  that  guarantees  certain  specified 
properties  in  return.  The  guarantees  of  the  system  (or  client  components)  may  be 
viewed  as  the  rules  specifying  legal  compositions  of  components.  When  components 
support  modular  reasoning,  component-level  maintenance  is  much  easier.  In  fact, 
it  has  been  argued  that  component-level  maintenance  is  technically  an  intractable 
problem  without  the  ability  to  reason  modularly  about  components  [WHH94].  When 
reasoning  modularly  about  the  behavior  of  a  component,  design  dependencies,  and  not 
integration  dependencies,  determine  what  other  components  must  be  examined  and 
understood  in  order  to  understand  specified  aspects  of  post-integration  component 
behavior. 

As  an  example,  consider  an  implementation  of  a  stack  designed  to  use  an  existing 
list  component  as  its  data  representation.  Stack  operations  such  as  Push  and  Pop  can 
be  implemented  with  list  operations  such  as  Insert  and  Remove.  In  this  case,  the 
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stJH'k  coiiipr^K'iit  has  a  design  (IcpciKlciicv  on  a  list  coiiiijoiK'iit .  Xow  assiinu'  that 
the  stack  iinplcnicntatioii  is  '^('iH’ric  it  is  |)araiii('t('ri/('(l  hy  th('  type  of  items  held 
l>y  the  stack,  hor  the  stack  imi)leinentation  to  Ix'  iiitexiated  into  a  s\'st<‘in.  it  must 
he  instantiated  with  the  typ('  of  item  to  he  h('ld  on  the  stack.  Assume  that  in  a 
particnlar  system,  the  stack  eompoiK'iit  is  in.stantiat('d  with  typ('  Message  (hdinerl  in 
a  component  providing  an  ahstract  data  tyi)e  (AI)T)  for  certain  kinds  of  me.ssagc's.  In 
thi^  particnlar  systf'in.  the  eompoiK'iit  fornu'd  hy  instantiating  th(>  stack  with  Message 
ha^  an  integration  de|)eiKlency.  hnt  no  design  d(']>end('ney.  on  th('  mc'ssage  component. 

Xow  sui)])ose  th('  stack  im])lementalion  is  not  eoni)l(’d  to  any  particular  list  im¬ 
plementation.  Instead,  assunu'  it  is  con])led  to  a  component  piau'iding  an  ahstract 
dcM  iiption  of  a  list  imi)lem('ntation  inelnding  the  strnetural  and  hehavioral  speci¬ 
fications  of  the  Insert  and  Remove  o])erations.  Wh<>n  int<'grat('d  into  a  particular 
system,  the  stack  im])lementation  must  Ix'  link('d  to  a  component  sup|)lying  a  ])artic- 
ular  list  implementation.  (.At  int(>gration  time  it  might  ev('n  he  linkt'd  indirc'ctlv  to 
one  or  more  list  imphunentations  with  final  hinding  d(>layed  until  run  tinu'.)  Within 
the  coiiti'xt  of  a  specific  system,  the  component  formed  hy  instantiating  the  stack 
will  have  an  integration  de]X'nd('ncy  on  the  com])onent  supplying  a  ])articular  list 
implementation.  Here  the  integration  dejx'iuh'ney  n'sults  din'ctly  from  the  design 
(h'pendency.  Xot('  that  the  integration  d('pend('ncy  is  a  much  stronger  coui)ling  in 
thi>  case  since-  it  n-eiuires  commitment  to  one  ])articular  imj)lem('ntation  wlx'reas  tlx' 
design  dependency  docs  not. 

Ill  order  to  /»////  understand  tlx'  hehavior  of  an  integrated  stack  com]X)nent.  we 
might  ix'erl  to  niiflerst aiul  asjx'cts  of  tlx-  lx‘ha\  ior  of  the  compoix'iits  ])nn'iding  tlx' 
stack  item  tyjie  aixl  list  imiilementation.  However,  to  a  gn-at  extent.  w(>  can  un- 
derstaixl  tlx'  tiedunior  exhiliite'd  hy  the  stack  operations  without  knowing  anvthing 
ahiiiit  the  tvjx’  (tf  items  held  hy  the  stack,  f'urt Ix'rmore.  w('  can  uixh'istand  how  aiifl 
why  the  stack  ojx'iations  work  corre’ctly  without  knowing  |)reci.s('l\'  how  the  list  is 
im])lement('d.  W'r  do.  how('V('r.  have-  to  understand  some  asjx'cts  of  tlx-  Ix'havior  of 
any  list  impli'inmitation  that  may  lx>  su])i)li(>d.  That  is.  w('  have  to  uixh'rstand  tlx- 
ramifications  of  the  devsign  coupling  to  a  com])onent  (h'serihing  list  helun  ior.  Tlx-  k('y 
jxiint  is  that  wc  can  n-ason  about  many  important  a.s|X'cts  of  tlx-  ('xecution  Ixdiavior 
produced  hy  the  stack  component  before  it  is  intf'grated  into  a  svstem. 


1.1.3  Behavioral  Relationships 

Mixlern  iirogramming  languages  provide  mechanisms  such  as  interface-only  com- 
])onentN,  generics  ( templat (-s).  inheritance',  and  run-time  disieatching  of  ojierations 
that  suppoit  \aiious  forms  of  abstraction.  \\  Ix'ii  ust'd  in  a  disci])liix'd  manner. 
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these  and  other  language  mechanisms  can  help  reduce  design  dependencies  and  en¬ 
code  behavioral  relationships  between  components.  For  example,  inheritance  is  of¬ 
ten  used  to  encode  the  behavioral  relationship  of  subtyping  [LW94].  Use  of  inher¬ 
itance,  however,  typically  increases  design  dependencies  between  components,  and 
thus  should  be  used  with  great  care.  Few  programming  languages  provide  mecha¬ 
nisms  that  directly  support  specification  of  component  behavior.  Rare  exceptions 
—  primarily  research  languages  —  include  Gypsy  [AGBH77],  Alphard  [ShaSl],  and 
RESOLVE  [SW94].  To  support  reasoning  about  program  behavior,  programming  lan¬ 
guages  may  be  augmented  with  a  behavioral  specification  language  (see,  for  example, 
[SW94,  DL96,  Jon90,  LvHKB087]). 

Software  engineers  maintaining  component-based  systems  need  to  understand 
both  when  it  is  possible  and  when  it  is  appropriate  to  substitute  one  component 
for  another  in  a  software  system.  The  possibility  of  component  substitution  is  de¬ 
termined  in  current  programming  languages  by  syntactic  constraints.  That  is.  if  two 
components  share  a  common  structural  interface,  then  it  naight  be  possible  to  substi¬ 
tute  one  for  the  other.  The  appropriateness  of  substituting  one  component  for  another 
depends  on  the  behavioral  properties  of  the  two  components  and  the  desired  changes 
in  system  behavior.  Thus  it  is  important  for  system  maintainers  to  understand  the 
behavioral  relationships  between  components  as  well  as  the  dependency  relationships 
between  components. 

The  purpose  of  studying  the  software  component  relationships  described  in  this 
work  is  to  concisely  express  design  dependencies  and  behavioral  relationships  between 
software  components.  These  relationships  provide  implementers  and  maintainers  with 
useful  information  about  how  components  may  and  should  be  linked  together  when 
integrated  into  component-based  systems.  Furthermore,  these  relationships  support 
the  goals  of  minimizing  design  dependencies  and  developing  components  about  which 
it  is  possible  to  reason  modularly.  Thus  software  component  relationships  can  aid 
maintainers  in  determining  when  one  component  may  appropriately  be  substituted 
for  another.  In  doing  so,  they  provide  a  useful  framework  supporting  maintenance  of 
component-based  software. 


1.2  The  Thesis 

The  work  presented  in  this  dissertation  is  based  on  three  assumptions.  First,  we 
assume  that  complex  software  systems  will  be  built,  to  a  large  extent,  from  existing 
software  components.  Second,  we  assume  that  maintenance  of  component  based 
systems  will  be  more  cost-effective  when  performed  at  the  component  level  rather 
than  at  the  individual  line-of-code  level.  Finally,  we  assume  that  large  component- 
based  systems  may  be  built  from  components  about  which  it  is  possible  to  reason 
modularly. 
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1  hr  fii>t  assiiinpt ion  is  (^asily  jnstifi('fl  sin(*('  (•()ni])()nr]it-l)as('(l  software^  nniso  is 
alrf'afly  hriiii;  ai)j)li(Hl  in  iiulnsfiy.  Stuclif’S  liav('  (hMiioiist rat(nl  tliat  tlu^  (M’onoinics  of 
Soft  warn  rcaisf'  niakf^  this  ai)])roacli  to  soft  wan'  (l('V('lo])iiiriit  very  coinpollinp;  [Pr('r)7. 
p.  71  i  .  .]mtifi(‘at ion  of  (Ik'  sf'f'oiul  assuni])tioii  is  hasc'd  on  tin'  ohsc'rvatioii  that  coin- 
pniHMit  n'plar’f'iin'iit  is  ^f'lu'rally  oasirr  tliaii  int('nial  (•oiui)()ii('nt  modification  wln'ii 
n‘])lac(*nicnt  coiu])on('nts  arc  available'.  When  r('])la(*('nH'nt  coni])oncnts  arc  not  avail¬ 
able.  (‘ithcr  ('xistinu  coinpoin’iits  must  In'  modifie'd  or  new  (‘omponents  developed  from 
scratch.  Both  of  tlu'sc*  options  are'  consid(*rabIy  more'  expe'iisive  than  re'usins  e^xist- 
imj.  e-om])f)in'nts  iSe'ISf),  p.  222].  The  thirel  assumptie)n  se'e'ins  plausible'  base'd  e)n  the' 
U'.'sf'arch  re’sidts  ente'd  e’arlif'r.  Jo  date',  the're'  are'  ve'ry  fe'w  ('xam])les  in  the'  lite'rature 
e>f  non-t ri\'ial  ap])lications  e*onstrue'te'd  from  e’e)mi)e)ne'nts  de'sit^neel  spe'e’ifie*ally  te)  sup¬ 
port  modidar  re'asonin,^.  Me)wever,  e-e)mme'reaal  software'  pae'ka.i’e's  d('\'('le)p('d  bv  Joe 
Hollingsworth  .se'rve  as  pre)of-of-prined])l('  [lle)in7].  We  be'lieve  that  as  the  importaiiea' 
of  modular  re'asoninr  In'conu's  me)r('  wide'ly  unel('rste)e)d.  other  ele've'Iopme'iit  e'fforts 
will  furtln'r  validate'  the'  thirel  assum|)tie)n. 

I^ase'd  eui  the'se'  assum])t ions,  this  disse'rtation  aelelre'ssf's  the  folle)wing  rese'areJi 

is>ue'.s. 


•  W  hat  relat ionshi])s  be'twe'e'ii  se)flware'  e*e)mpe)n('nt s  elo  de'signers  ne'e'd  te)  ex])Iie‘itly 
elocunif'nt  to  be'st  support  e*e)m])e)neiit-le've'l  maintenane‘e'  of  e*e)mpe)nent-base'd 
systf'ins'." 

•  How  can  the'se'  e’omponent  re'lationships  be'  use'el  te)  sup])e)rt  e‘e)m])e)neiit-l('vel 
maint(‘nane*e'? 

•  Hov  can  the'se'  re’lationships  be'  ('xi)re'sse'el  in  me)el('rn  pre)”ramiiiing  language's? 

In  ainwe'ring  the'se  cpie'st ie)ns,  this  elissertatie)n  de'fends  the  following  the'sis: 

C  omponent-lf've'l  mainte'uanea'  e)f  software  systems  may  be  base'd  on  a 
small  sf't  of  be'lnu'ioral  anel  ele'pende'Ue’v  re'lat  ie)nships  In'twe'cn  se)ft\\'are' 
e‘omi)one'nts.  furthe'rme)re'.  these'  r('latie)nshi])s  can  be  e'ne‘e)ele'd  with  the' 
language  me'e'hanisms  ])ro\-iele'd  by  me)dern  pre)gramming  languages,  al¬ 
though  not  as  e'asily  as  she)uld  be'  possible'. 

1.3  Related  Research 

The'  re'Sf'areJi  i)re'sente'd  in  this  elisse'rtatie)n  builels  upe)n  IdTSOIA’E-relatc'd  re'- 
se'arch  :HarOf).  HW9].  EehvDO.  MW’OO.  W'OZf)],  He)in2,  SW'9  b  Eelw9r),  W'e'i97]  per- 
foime'd  b\  the'  Hc'usable'  Se)ftware'  IT'se'arch  Gre)Up  at  The  Ohie)  State'  I  nive'rsity. 
Jin'  IH.S()IA  I',  language'  and  diseipline'  uniquely  addre'.ss  many  e)f  the  fundamental 
proble’ins  in  e‘ompe)ne'nt-bas('d  .se)ftware'  engineering.  In  partieadar.  the  RESOL\’E 
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approach  supports  formal  behavioral  specification  of  components  and  efficient  com¬ 
ponent  implementations  about  which  it  is  possible  to  reason  modularly.  The  property 
of  modular  verifiability,  exhibited  by  RESOLVE  components,  is  critical  to  reasoning 
about  the  behavior  of  component-based  systems.  Many  of  the  commonly  practiced 
object-oriented  techniques,  however,  fail  to  support  the  property  of  modular  verifia¬ 
bility  [Sny86,  Edw93]. 

The  RESOLVE  language  primarily  supports  component  adaptation  through  para¬ 
metric  polymorphism  (generics).  The  ACTI  model  of  software  subsystems  developed 
by  Edwards  provides  a  formal  model  of  the  semantics  of  parameterized  (and  non- 
parameterized)  components.  ACTI  has  been  used  in  defining  a  formal  semantics  for 
RESOLVE  [Edw95].  RESOLVE,  and  especially  ACTI,  have  been  influenced  by  the 
research  into  parameterized  programming  by  Goguen[Gog84,  Gog86].  The  research 
we  present  in  this  dissertation  adopts  the  basic  component  model  of  ACTI. 

During  the  past  decade,  most  research  in  component-based  software  has  focused 
on  object-oriented  techniques.  Widely  used  programming  languages  such  as  C-|— I- 
[Str93]  and  the  1995  revision  to  Ada^  [Int95b]  provide  language  mechanisms  sup¬ 
porting  both  parametric  polymorphism  and  object-oriented  techniques.  Several  well- 
known  authors  have  written  extensively  about  the  construction  of  object-oriented,  or 
“object-based”,  software  components.  Grady  Booch’s  “Booch  Components”,  imple¬ 
mented  in  Ada83  [Boo87],  have  served  as  the  most  widely  adopted  model  for  software 
components  written  in  Ada.  After  his  initial  work  in  Ada,  Booch  re-implemented 
his  component  library  in  C-b- 1-.  In  describing  the  design  of  his  C-t-+  components 
[Boo90,  Boo94],  Booch  discussed  the  use  of  object-oriented  language  mechanisms  and 
templates.  Banner  and  Schonberg  [BS92]  examined  implementing  a  software  compo¬ 
nent  library  in  Ada9X,  a  preliminary  version  of  the  1995  Ada  definition.  Building 
upon  this  work  and  with  concurrence  from  Booch,  David  Weller  has  begun  imple¬ 
menting  “The  Ada  95  Booch  Components”  [Wel95].  Weller  is  currently  implement¬ 
ing  these  components  using  Ada’s  new  object-oriented  features  in  a  fashion  similar 
to  Booch’s  use  of  C-H+’s  object-oriented  features.  Recent  work  by  Magnus  Kempe 
[Kem95]  examining  the  use  of  Ada’s  new  language  mechanisms  for  implementing 
software  components  also  appears  to  be  heavily  influenced  by  Booch’s  work. 

As  pointed  out  by  Hollingsworth  [Hol92],  Booch’s  original  Ada  components  fail 
to  satisfy  the  goals  of  the  RESOLVE  approach.  For  example,  Booch’s  polylithic 
components  (e.g.,  list,  tree,  and  graph)  rely  on  reference  semantics.  As  a  result, 
systems  using  these  components  are  not  amenable  to  modular  reasoning.  Booch’s 
C-I-+  components  and  the  Ada  approaches  described  by  Weller  and  Kempe  also  fail  to 
use  language  mechanisms  in  a  manner  consistent  with  modular  reasoning.  Aside  from 
the  work  of  Falis  discussed  below,  there  does  not  appear  to  be  any  published  research 

"In  this  document,  the  term  “Ada”,  without  further  qualification,  is  used  to  refer  to  the  1995 
definition  of  the  Ada  programming  language,  previously  known  as  Ada9X,  and  sometimes  called 
Ada  95. 


7 


into  how  the  iK'w  laiii^iiasc  iiK'diaiiisins  of  Ada  can  he  ai)i)li('(l  to  tlic  coiistniction  of 
mod  Ilia  ii\-vcrifial)lc  compoiicnf-hasc'd  soft  wane 

Aiiotlif'r  w('ll-kiiowii  aiiilior  who  has  writK'ii  cxt('iisi\-('ly  about  n'usal)l(>  softwan' 
components  is  Bertrand  Meyer  [Mey88.  Ah'yOl],  Mt'vc'r  is  a  leading  ad\()eat('  of 
ol.jcei-oriented  |)ro,!;rainmin,u;  and  is  the  ])rineipal  d('V('loper  of  the  Eifh'l  pro,<!,rain- 
niinu  lanyuaye  :Mey88'.  Meyer  [MeySfi]  and  Seidewitz  [SchO  1]  have  written  about  the 
ielati\e  strenytlis  and  weakiK’sses  of  inli('ritane('  and  gemeries  (|)arainet rie  ])olynK)r- 
phi'in!.  Both  antliors  eoneludf'  that  tin'  two  approaches  may  be  ns('d  in  a  eonii)le- 
nientai\  manner.  How(‘\'er.  tliere  app('ars  to  Ix'  \’ery  little  r(*s('ai'eh  into  tin'  combined 
api)lieafion  of  these-  two  api)roaeh('s.  espe-eially  for  practical  inpx-rative'  pro>>;rammin'; 
lanmiayes  such  as  Ada  and  C'+  +  . 

1  he  Ada  Ian, ullage-specific  asjx'cts  of  this  work  |)re,sented  in  Chapter  5  share  goals 
similar  to  those  of  work  on  the  d('veloi>m('nt  of  tlx-  HES()L\’E/C+-f  (RCPP)  disci- 
plini'  WeiOi  .  I  he  P.\9b  approach  |)res('nted  in  Cha])ter  5.  how('V('r.  diflers  from  the 
Hf  PP  approach  in  seve-ial  as|X'cts,  first,  in  Chapte-r  1  wr  focus  on  iinde-rstanding 
how  a  wide  variety  of  langna,g('  nu'chanisms  may  Ix’  n.sed  best  in  component-bas(‘d 
software  ('iigineering.  Second,  the  n-st-arch  primarily  investigatt's  the  language  mech- 
ani-ms  of  .\da.  which  differ  in  nuiny  ways  from  those  of  C-l--f .  Third,  tlx-  a])i)roach 
to  embedfling  the  Pf.SOlA  f-,  huiguage'  into  .Ada  is  fuixlamentallv  diffen-nt  from  that 
lis.sl  bv  ffCfdh 

1  Ix’  PC  PP  discipline  rt'lies  lx't)\‘ily  on  tlx-  ust-  of  ])re])roc('ssor  macros  tlnit  ser\(' 
to  make  tlx'  -sonree"  language  of  HCPP  a]>ix'ar  snbstantially  different  from  normal 
C'--.  The  bem-fits  of  this  ai)])roach  include  making  the  RESOIA’E  atxl  .ACTI  per- 
spectivf's  nx)r('  ('xi)licil  in  the  .soiirct-  languagt*.  hiding  anixtying  C-I-+  syntax,  atxl 
improving  imiintaitiability  by  n-ducing  source  n'dnixhincv.  The  a])proach  to  R.AOo 
l)re-^ented  in  Chaptc-r  b  d(X‘s  not  re(|uire  tlx-  ust-  of  a  prt-proct's.sor.  Following  tlx-  ITAOb 
tlisci])line  etitails  coding  directly  in  .Ada.  One  benefit  of  this  aitproach  is  that  R.AOb 
Use>  language  meclxinisms  of  .Ad;i  hirgely  as  they  were  intt-iuh'd  to  lx-  irst-d.  This 
approach  should  make  explaining  the  rtttiomde  for  R.ADb's  use  of  various  language 
mechatiisms  etisier.  .Anotlx-r  benefit  is  that  maintenaixe  of  R.A9.’)  code  is  niainte- 
naix-e  of  .Ada  code,  Thus,  amilysis  atxl  maintt-nanct'  tools  avaihtbh'  for  .Ada  should 
be  dio'ctly  ai)plicable  to  R.A9.)  source  codt-.  finally,  a  possibh-  pr;x'tic;tl  Ix-nefit  of 
this  a])])r();x  h  is  th;it  ITA9.)  m;t,\'  lx-  mort-  acct-ssible  to  ('X])eri('nced  .Ad;i  programmers 
tluiti  RCPP  is  to  exjierieix'ed  C’-F-f  progr.immers. 

I  he  research  presented  in  Chaptt'r  •:>  jilso  is  rehtted  to  an  (-arly  ('xploration  of 
mapping  RESOIA'E  to  the  199.-)  version  of  Ada  by  Ed  Palis  at  Thompson  .Software 
^fa!9.)  .  falls  work  centers  aronixl  tlx-  use  of  the  bridge  atxl  factory  dt-sign  ])att('rns 
CilI.lX  9.)  to  sup]x)rt  run-tinx’  st-lection  of  compoix'iit  opt-rations  in  .Ada.  falis'  work 
itifbx'ix'cd  Work  by  f,dward.s  on  run-tinx’  seh-ctabh*  (Lt'vt'l  2)  compoix-nts  ixtw  incor¬ 
porated  into  RCPP.  R.A9b  has  borrowt-d  sonx-  idt-as  from  Falis'  work,  but  takes  a  very 
diffeif'ut  approtich.  1  lx-  R.A9.')  discipliix'  pn-sentt-d  in  Chapter  b  does  not  use  dynamic 
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binding  mechanisms.  The  work  of  Palis  assumes  that  dynamic  binding  will  be  used. 
While  we  discuss  dynamic  binding  in  Chapter  4,  its  incorporation  into  RA95  would 
add  significant  complexity  and  does  not  appear  necessary  to  encode  the  component 
relationships  presented  in  Chapter  3. 

Another  area  of  related  RESOLVE  research  is  the  work  by  Joe  Hollingsworth 
on  the  RESOLVE/Ada  discipline  based  on  the  1983  version  of  Ada  (RA83)  [Hol92]. 
Hollingsworth’s  research  demonstrated  that  the  RESOLVE  approach  could  be  applied 
using  a  programming  language  other  than  RESOLVE,  namely,  Ada83.  Since  the 
development  of  RA83,  both  RESOLVE  and  Ada  have  changed.  The  major  change 
to  RESOLVE  has  been  the  incorporation  of  many  of  the  ideas  of  the  ACTI  model 
of  subsystems  [Edw95].  The  ACTI  model  provides  a  formally-based  framework  for 
describing  software  components  and  the  relationships  between  components.  In  1995, 
a  major  revision  to  the  Ada  language  was  finalized  and  a  new  language  standard 
was  established.  The  revised  Ada  includes  many  new  language  mechanisms  that 
are  useful  in  describing  components  and  component  relationships  as  characterized  by 
ACTI.  While  the  RA95  discipline  preserves  many  aspects  of  RA83,  the  focus  of  this 
research  has  been  on  the  use  of  Ada’s  new  language  mechanisms  and  exploration  of 
ACTI-inspired  component  relationships. 

Many  researchers  have  worked  on  formal  reasoning  about  object-oriented  pro¬ 
grams.  Most  of  this  related  work  focuses  on  the  formal  definition  of  behavioral 
subtyping  [CW85,  LW90,  LW94,  SG95,  DL96].  The  Theta  programming  language 
[LDGM95,  LCD''‘94],  developed  at  MIT,  incorporates  ideas  from  this  work.  Theta 
provides  separate  mechanisms  for  type  hierarchy,  parametric  polymorphism,  and  in¬ 
heritance.  The  separation  of  type  hierarchy  from  inheritance  allows  related  types  to 
have  independent  implementations  and  unrelated  types  to  have  related  implementa¬ 
tions  [LGD+94,  p.  1].  RESOLVE  also  provides  this  flexibility,  but  the  inheritance- 
based  type  systems  of  Ada  and  C-f- 1-  are  more  restrictive. 

1.4  Organization 

The  remainder  of  this  dissertation  is  organized  as  follows.  In  Ghapter  2,  we 
develop  a  framework  and  notation  for  describing  behavioral  relationships  between 
software  components  and  identify  fundamental  component  relationships.  In  Chap¬ 
ter  3,  we  define  a  useful  set  of  component  relationships  based  on  those  identified  in 
Chapter  2  and  describe  how  they  may  be  used  to  support  component-based  soft¬ 
ware  development  and  maintenance.  In  Chapter  4,  we  discuss  how  the  relationships 
described  in  Chapter  3  may  be  encoded  using  the  language  mechanisms  of  modern 
programming  languages.  In  Chapter  5,  we  describe  the  RA95  discipline  and  show 
how  the  component  relationships  presented  in  Chapter  3  are  encoded  in  RA95.  Fi¬ 
nally,  Chapter  6  summarizes  the  research  presented  in  this  dissertation,  describes  the 
contributions  made  by  this  work,  and  proposes  suggestions  for  further  research. 
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CHAPTER  2 


A  MODEL  OF  BEHAVIORAL  RELATIONSHIPS 
BETWEEN  SOFTWARE  COMPONENTS 


In  this  chapter  we  develop  a  model  of  behavioral  relationships  between  software 
components.  These  relationships  serve  as  a  basis  from  which  we  derive  the  more 
practical  set  of  relationships  described  in  Chapter  3.  Section  2.1  discusses  the  re¬ 
quirements  for  interchangeable  software  components  and  motivates  the  need  for  the 
relations  developed  in  the  subsequent  sections.  Section  2.2  describes  how  components 
and  their  associated  behavior  are  modeled.  In  Sections  2.3  and  2.4  we  define  confor¬ 
mance  and  dependency  relations  in  terms  of  the  behaviors  described  by  components. 
Section  1.3  reviews  related  research  and  Section  2.5  summarizes  the  chapter. 

2.1  Interchangeable  Components 

As  briefly  discussed  in  Chapter  1,  one  of  the  differences  between  most  physical 
systems  and  software  systems  is  the  difficulty  involved  in  replacing  whole  components 
and  consistently  achieving  a  desired  effect.  For  example,  consider  a  common  table 
lamp  composed  of  components  such  as  a  base,  a  switched  socket,  an  electrical  cord, 
a  shade,  and  light  bulb.  We  can  change  the  behavior  of  the  lamp  simply  by  replac¬ 
ing  one  light  bulb  with  another.  Much  more  complex  physical  systems  offer  similar 
possibilities.  For  example,  most  desktop  computers  are  easy  to  “upgrade”  by  adding 
new  components  or  by  replacing  existing  components  in  toto.  In  fact,  many  desktop 
computers  are  designed  so  it  is  possible  to  remove  the  central  processing  unit  and 
replace  it  with  a  newer,  more  powerful  version.  We  would  like  to  be  able  to  maintain 
component-based  software  similarly. 

2.1.1  Component-Level  Maintenance 

Component-level  maintenance  involves  changing  the  behavior  of  a  software  sys¬ 
tem  in  useful  and  predictable  ways  by  removing  and  replacing  software  components 
rather  than  by  modifying  individual  lines  of  executable  code.  Reasons  for  changing 
a  system’s  behavior  include; 
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•  iin])r()viii^  syst ('111  pf'rforinaiicf'. 

•  arldinn  nrw  fuiictionalit y, 

•  a(la])tini^  tlio  syst('iii  to  lu'w  liardwan'  or  syst('ni  soft\var(\  and 

•  corrf'ct inn;  d(‘f('(‘ts  in  f'xistiiin;  functionality. 

1  lif‘  first  two  of  tlics('  activitif's  ar('  (‘alh'd  prrfi'rfivi'  in(}inf(i}anr(\  Tlu'  last  two  ar(^ 
calh'd  (ifl(i])firf  iiiainif  vanf'c  and  rnrrcrtirr  in(}iiif(ii(nir(\  n^sjx'ctivf'lv.  Acc'ording  to 
one  wid(‘Iy-cit(‘d  stiuly  of  lu'arly  of)()  software'  projc'cts,  approximately  7(Y/(  of  inain- 
t('nanef'  costs  about  half  of  tli('  total  lifc'-cych'  costs  of  tyj)ical  software  systems 

an'  attribiitabh'  to  perfective'  and  adaptive  maint('nancf'  [LBSBSO].  Ch'arlv  any 
approach  that  mak('s  it  f'asic'r  for  software  ene,in('('rs  to  im])ro\'e  swstc'iii  ])erforniance, 
exti'iid  s\'stf'm  functionality,  and  adapt  systt'iiis  to  new  ('iivironments  can  have  a  sip;- 
nificaiit  impact  in  r('du(‘in,e;  software'  (‘osts.  C'ompoiient-le've'l  maintenaiu‘('  (*an  reduce 
the'  effort  re'ciuired  for  e'ach  of  the'se'  mainte'iiance'  tasks. 

For  conpione'ut-le've'l  maiiite'iiaiK’e'  to  he  ])ossiI)Ie',  software  enginee'rs  must  he  able 
tei  answe'r  the'  followin^e;  cjuestion. 

Given  syste'iii  (or  compone'iit )  P  which  use's  compone'iit  }  \  can  component 
A  l)e  suhstitiite'd  for  )'  in  P  and  maintain  all  of  the'  ])ropertie\s  that  P 
re'rjuire'd  of  ] '? 

In  oreh'r  to  answe'r  this  fjiu'stion  on  a  syste'inatic  basis,  thre'e'  issue's  must  be'  ael- 
dre'-s^efl;  the'  stnu'tural  conformance'  of  the  lU'w  compone'iit,  the'  Ix'havioral  confor- 
maiie‘('  of  the'  new  compone'iit.  anel  the  mechanie’s  of  the  substitution.  \\v  discuss 
conhainance  issue's  in  this  chapte'r.  We  eliscuss  mechanisms  supjiortini;'  the'  me'chan- 
ics  of  substitution  in  Cdia])te'r  1  anel  provieh'  examples  in  (dia])ter  5. 

Software'  components  must  be'  de'si,u;n('(l  and  imidemente'd  so  that  system  main- 
taine'r-  can  substitute'  one'  (‘omjxuient  for  another  anel  unele'rstanel  the  ('ffe'cts  of  doing 
So  eul  the'  syste'ui  s  be'liavior.  A  ke'v  (‘halh'iige'  is  to  make'  it  ('asie'r  for  a  maintainer  to 
achie'\-('  eh'sire'el  changes  in  syste'iii  be'liavior  without  causing  any  unde'sire'd  clianges 
in  be'liavior.  For  e'xam])le'.  to  inpirove'  e'xe'cution  time,  we'  might  want  to  replae*e'  one' 
(‘e>ni])eine'nt  with  anothe'r  that  jirovide's  a  more'  efficie'iit  imple'iiie'iitation  of  some  func¬ 
tionality.  While'  it  is  inpieirtant  that  the'  change  improve's  system  pe'rformaiice,  it 
i>  jiHt  as  im])ortant  that  use'  of  the'  iie'w  component  ])re'serv('s  the'  eiriginal  svstem 
fiine-t ioiiality.  In  ])i'ae‘t ie*e'.  the'  (|ue'stioii  aske'd  alxn'e'  is  difficult  to  ansv’e'i'  (“orre'euly 
anel.  in  fact,  is  unele‘cielal)I('  in  the'  ge'iieral  case'.  X('\'('rt lu'le'ss,  if  software'  components 
are'  de'signeel  and  imple'mente'd  with  the'  objee-tive  of  substitutability  in  minel,  this 
ejue'stioii  is  mue-h  easie'r  to  answei’  ae'e'urate'ly.  The  j)rine-i])al  re'ason  for  stuelying  the' 
(‘e niipone'nt  re’lationships  eh'fiiu'el  in  this  elisse'rtation  is  tei  ('liable'  software'  engine'e'rs  to 
aii'-we'r  thi>  ejuestion  more'  ('asilv. 
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2.1.2  The  Role  of  Interface  Specifications 


Well-specified  component  interfaces  make  possible  component-level  maintenance 
of  physical  systems.  Furthermore,  standardization  of  interface  specifications  makes 
component-level  maintenance  of  most  physical  systems  commercially  viable.  An  in¬ 
terface  specification  describes  the  requirements  that  a  component  must  satisfy  in 
order  to  interact  with  other  “external”  components,  that  is,  other  components  in  its 
environment.  Note  that  an  interface  specification  must  address  requirements  on  both 
sides  of  the  interface.  For  example,  in  the  case  of  a  light  bulb,  the  standardized  inter¬ 
face  specification  must  describe  the  width,  depth,  and  threading  (and  other  details)  of 
a  light  bulb  base.  Such  a  specification  places  requirements  both  on  conforming  light 
bulbs  and  on  lamp  sockets  designed  to  use  conforming  light  bulbs.  That  is,  both  light 
bulb  designers  and  light  bulb  socket  designers  must  refer  to  the  common  interface 
specification  in  order  for  component-level  maintenance  of  lamps  to  be  possible. 

The  importance  of  w^ell-defined  interfaces  for  softw^are  components  has  been  un¬ 
derstood  for  many  years.  Many  programming  languages  provide  support  for  defining 
softw^are  component  interfaces.  However,  most  programming  language  support  for 
interface  specifications  only  addresses  structural  aspects  of  the  interface,  and  not  be¬ 
havioral  aspects.  For  some  physical  components,  such  as  nuts  and  bolts,  interface 
specifications  only  need  to  address  structural  issues.  How'ever,  even  for  a  component 
as  simple  as  a  light  bulb,  an  interface  specification  may  need  to  address  more  than 
purely  structural  requirements.  The  light  bulb  interface  specification  may  need  to 
specify  minimum  and  maximum  voltages  and  amperages  required  for  proper  bulb 
illumination  and  state  that  when  an  appropriate  current  is  applied,  the  light  bulb 
wall  illuminate.  In  the  case  of  computer  components,  interface  specifications  clearly 
must  describe  much  more  than  pin  counts,  shapes  and  sizes  in  order  for  components 
to  interact  successfully. 

To  determine  if  one  softw'^are  component  may  be  substituted  appropriately  for  an¬ 
other,  both  structural  conformance  and  behavioral  conformance  must  be  addressed. 
Structural  conformance  is  concerned  wdth  the  names  and  signatures  of  component  fea¬ 
tures.  In  many  programming  languages,  the  structural  conformance  of  a  component 
to  an  interface  specification  is  determined  partly  by  type  checking.  In  statically- 
typed  languages,  structural  conformance  is  checked  either  by  the  compiler  or  by  the 
linker  w^hen  a  component  is  integrated  into  a  system  —  prior  to  runtime.  Behavioral 
conformance  is  concerned  wdth  w^hether  a  component’s  operations,  w^hen  executed, 
wall  produce  the  desired  (specified)  effect.  Checking  behavioral  conformance  is,  in 
general,  much  more  difficult  than  checking  structural  conformance.  The  principal  ap¬ 
proaches  to  checking  behavioral  conformance  are  testing  and  verification  techniques 
(both  formal  and  informal).  Both  approaches  have  their  strengths  and  w'eaknesses. 
Whichever  approach  is  used  (a  combination  of  verification  and  testing  is  typically  the 
best  strategy),  interface  specifications  that  clearly  describe  behavioral  requirements 
are  essential. 
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2.1.3  Substitutability 


A.''Siiiiir  that  two  coiupoiu'iit s  A  and  )  liavr  woll-sjx'cifind  structural  and  Ixdiav- 
ioral  interfaces  descrihiui;  tlu'  services  they  luovide  and  the  s('rvices  they  retjuire  from 
any  system  into  which  they  are  iuteer;it(>d.  It  would  Ix'  ust'ful  to  know  wlu'tlx'r  A' 
is  suhstitiitahh'  for  )'  in  (iin/  pro.nram  (com|X)ueut-l)as('d  system),  rufortuuately. 
without  kuowiuy  tlx'  specific  Ix'luuior  that  some  system  ('xjx'cts  of  i  ,  w<'  cauiiot  d('- 
termitu'  if  A'  can  Ix'  suhstit  iitecl  for  )'  exct'pt  in  ti  few  d(\u;eiH'rate  cases.  If  A'  and  )'  are 
identical  coupxxx'uts  (two  diflerc'iit  comj)oueuts  with  differt'ut  names,  hut  identical 
content)  then  w('  imty  stifely  coticlndc'  tlnit  A  is  snhstil utithh'  for  I  in  all  progratns. 
IIowe\er.  in  this  case,  thert'  is  ch'aiiy  no  r(’ason  to  mak(‘  tin'  snhstitntion  since  it 
slioiihl  not  chatiee  the  Ixdiavior  of  tin'  syst('m  in  any  respect.  A'  atid  V  might  also 
he  iK'arly  ich'iitical  ('xcej)t  tlnit  for  sotne  itiixits  ati  o]x'ration  stipplit'd  h>-  )'  goes  into 
ati  itifiniti'  loop  whereas  the  corri'sponding  operation  in  X  does  not.  If  we  maki'  the 
reasotiahle  assumption  tlnit  no  ••correct"  program  woitld  entt'r  an  infinitt'  looj).  then 
we  may  cotii’liide  in  this  case  that  A  may  Ix'  snhstituti'd  for  )  in  any  (correct)  pro¬ 
gram.  Despit ('  the  fact  that  A’  and  implement  different  Ix'havior.  the  assum])tion 
ensures  that  no  correct  |)rogr;im  would  use  )'  or  A'  in  a  way  that  could  distinguish 
hetwec'ii  the  helnniors  they  imph'iiu'nt. 

.An  c'liiheddefl  real-time  systi'in  might  ])lac('  timing  and  resonrci'  ntili/ation  re- 
(|nirements  on  the  components  it  nsc's.  In  this  case.  simpl>'  com]);iring  the  functional 
helnnior  of  two  components  is  not  siifficit'iit  for  (h'termining  snhstitutahility.  For 
example,  cotisirler  the  east'  where  A'  is  idt-nticjil  to  )'  exct'pt  that  it  has  an  additional 
opeiation  tlnit  does  not  afh'ct  any  statt'  ohst'rvahle  hy  any  of  the  com]xinent  s  other 
o])erations.  Mt're  the  Ix'lnu'ior  provided  hy  A  might  apjx’ar  to  he  a  snh-lx'lnivior  of 
that  pnivifled  hy  )'.  Ilowt'vt'r.  if  tlx'  increased  mt'inory  rt'tiuired  to  store  tlu'  codt'  of 
A  s  adflitional  opf'iation  (whether  or  not  it  is  used)  exceeds  tht'  resonret'  ntili/ation 
litnits  that  a  progrtitn  places  on  comixxK'iit  )'.  tlit'ii  X  is  not  suhstitiitahh'  for  )'  in 
that  system.  lort imat elv.  most  .systi'ins  do  not  hump  up  against  extri'ineK'  strict 
limits  on  resonrci'  ntili/ation  and  opt'ration  ('xc'cntion  tinx'. 

In  general,  tlx'ii.  the  onl>-  w;iy  to  ch'li'iniine  if  comixiiK'iit  A’  is  snhstitutahle  for 
com])onent  }  is  within  the  coiiti'xt  of  a  sjx'cific  syslc'ui  whert'  tlx'  r('(|nir('ments  for  }  . 
and  thus  for  any  compoiK'iit  ri'plaeing  )  .  ari'  ch'.irly  unch'istood.  Tlx'  rt'cinirements 
a  sysO'in  or  component  has  on  anotlu'r  comporn'iit  may  he  exjiressed  in  terms  of  an 
intf'ifaci'  specification.  I  hat  is.  if  program  P  can  nst'  any  component  that  jirovides 
the  heha\-ior  ch'scrilx'd  hy  inti'ifact'  sjiecification  .S',  then  /'  should  not  he  eucodt'd  to 
(h'liend  on  a  s]x'cific  compom'nt.  say  for  examph'.  D.  If  we  ('iicixh'  P  in  snch  a  way 
that  it  may  Ix'  linki'd  to  any  component  imph'inenting  tlx'  hehavior  (h'serihed  hy  .S. 
till'll  coniponent-h'vi'l  snhstitntion  hecomi's  possihh'.  If  both  A"  and  )’  conform  to 
interface  sjiecification  S.  then  A  may  he  snhstituti'd  for  I  vifli  vcsprrf  to  S  in  auv 
program  P. 
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Figure  2.1:  Conformance  and  Requirement  Relationships  -  Physical  Components 


Consider,  again,  the  analogy  to  a  table  lamp.  A  standard  component  integrated 
into  most  table  lamps  is  a  switched  bulb  socket.  A  lamp  manufacturer  is  likely  to 
select  the  kind  of  socket  to  be  used  in  a  particular  lamp  from  a  catalog  of  existing 
bulb  sockets.  A  key  factor  in  the  selection  of  a  socket  is  that  it  be  designed  to  accept 
standard  light  bulbs.  A  description  of  the  bulb  socket  selected  should  specifically  state 
that  the  socket  requires  a  bulb  conforming  to  the  standard  light  bulb  specification. 
The  socket  description  clearly  should  not  require  a  specific  brand  of  bulb.  In  addition 
to  varying  by  brand,  acceptable  light  bulbs  may  also  vary  in  power  consumption, 
radiance,  color,  durability,  and  other  characteristics  not  fixed  by  the  standard  light 
bulb  specification.  Since  many  different  kinds  of  light  bulbs  are  designed  using  this 
specification,  bulb  sockets  that  require  bulbs  that  conform  to  this  specification  will 
work  with  many  different  kinds  of  light  bulbs. 

Figure  2.1  depicts  the  conformance  and  requirement  relationships  involving  light 
bulbs,  light  bulb  sockets,  and  a  light  bulb  specification.  The  arrows  on  the  bottom 
indicate  that  the  light  bulbs  shown  satisfy  the  requirements  described  by  the  spec¬ 
ification.  The  arrows  on  the  top  indicate  that  the  bulb  sockets  require  a  light  bulb 
(any  light  bulb)  that  conforms  to  the  specification.  Together,  these  two  design  rela¬ 
tionships  allow  construction  of  lamps  for  which  component-level  maintenance  (bulb 
replacement)  is  possible. 

The  analogy  between  physical  components  and  software  components  is  not  perfect. 
Nevertheless,  the  role  of  behavioral  interface  specifications  for  software  closely  par¬ 
allels  the  role  of  interface  specifications  for  physical  components.  Figure  2.2  depicts 
relationships  between  software  components  analogous  to  those  shown  in  Figure  2.1 
for  physical  components.  The  shaded  rectangular  boxes  at  the  bottom  of  the  figure 
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Fi.uiirf'  2.2;  (  niif(>rnianf*('  and  R(‘(iuirrinont  r{('lat ioiiships  Software'  Coinpoiu'nts 


(f‘pir‘t  two  (liff(‘roiit  iinple'nu'iitatioiis  of  a  list  data  typo  that  coujonu  to  the'  list  iiitor- 
farf'  spf'oifioatioii  ch'piote'd  hy  tlu'  oval  box  in  tli('  (’('iitor.  Tlu'  two  hoxe'S  at  tlu'  top  of 
th('  diaui'ani  d('])iot  t\\‘o  difloi  f'iit  (*oni])oiK'nts  ('acli  of  which  7yy/////y'  an  iniph'inontation 
(•(Hifoniiini;  to  tlif'  list  sj^'eafioation.  1  hv  stack  aiul  (iiu'iu'  iin])l('niontations  on  tlu'  to]) 
aio  (‘hf  nf  conipoiH'nt s  with  r('spf'c*t  to  tlu'ir  d('])ond('iu'y  on  a  list  iinph'inontation. 
( intf'iii'at fvl  into  a  software'  systf'in,  ('ae*h  e)f  tlu'se'  oe)nipononts  must  he'  linke'd  to 
a  si)f'oific  list  iniploniontatie)n.  ne)we'vor,  de'signing  (ind  iiupUiurnfinfj  (‘liont  (*e)in])e)- 
iir'iits  so  that  the'v  de'])e'nd  e)n  l)e'havie)ral  inte'rfaoo  sju'eafications  for  the'  (‘e)ni])one'nts 
thoy  use'  rathf'r  than  on  spe'oifie*  iin])le‘inontatie)ns.  make's  it  possible'  te)  substitute  e)iie' 
iin])If'nie‘ntat ie)n  of  the'  spe'eafie'd  be'havie)r  fe)r  ane)the'r. 


2.2  Components  and  Behavior 

In  this  section  we'  de'seaabe'  a  inexle'l  of  software'  (■e)mpe)nents  and  the  be'havior 
a'^stKaate'd  with  the  inexle'le'd  e*e)in])e)ne'nts.  Idius  far.  we  have'  be'e'ii  using  the  term 
softwaie'  eonipe)ne'nt  infoiaiially  te)  re'fe'i*  te)  a  unit  of  ce)ele'  whi(‘h  might  l)e'  iiK'orpo- 
rated  into  an  e'xeeait able'  softw'are'  syste'in.  In  the'  me)de'l.  we  bre)aden  the  elefinitie)n  e>f 
“software'  (‘om])e)ne'nt  to  inclueh'  behavie)ral  inte'rfaea'  sj)e(afie-ations  and  j)arameter- 
i/e'd  module's  eadlf'd  te'inplat e's.  The'  meule'l  ])lace's  very  fe'w  ee)nstraints  on  the'  si)ecafic 
form  aiul  eonte'iit  of  ee)m])on('nt s.  in  orde'r  te)  maintain  language  indepenele'nee.  But 
for  tlie'  purpose's  e)f  unele'rst aneling  the'  meule'l.  ee)nside'ring  a  (‘e)mpe)nent  as  either  a 
s])eeafication  or  as  an  iini)le'mentatie)n  e)f  an  abstrae-t  data  tyi)e  (ADT)  will  not  le'ad 
the'  le'aeler  astray.  In  Cha])te'i'  -1.  we'  discuss  specific  ways  in  whieT  (‘omj)oneiits  may 
be'  re])rese'nte'd  using  si)e'eafie*atie)n  and  pre)gramming  language's. 


If) 


The  model  of  component  relationships  described  in  this  chapter  consists  of  four  dis¬ 
joint  sets  of  software  components;  Cl  {concrete  instances),  CT  {concrete  tem¬ 
plates),  AI  {abstract  instances),  and  AT  {abstract  templates).  The  model  also 
includes  the  set  M  of  mathematical  theory  modules  (math  modules,  for  short). 
For  convenience,  we  define  the  set  .C  =  Cl  U  CT  U  AI  U  AT  of  all  modeled 
components  and  the  set  [/  =  C  U  Af  of  all  modeled  syntactic  units.  Elements  oiCI 
and  CT  are  concrete  components  that  describe  how  the  behavior  of  operations  is  im¬ 
plemented.  Elements  of  AI  and  AT  are  abstract  components  that  serve  as  behavioral 
interface  specifications.  The  components  in  CT  and  AT  are  templates  while  those  in 
Cl  and  AI  are  not  (they  are  instances).  Elements  of  M  define  mathematical  theories 
which  provide  the  foundation  for  defining  the  semantics  of  all  elements  of  C. 

All  units  in  U  must  be  encoded  in  some  language  L  appropriate  for  specifying 
and  implementing  program  behavior  of  interest.  L  may  be  a  single  integrated  speci¬ 
fication  language  such  as  RESOLVE  [SW94]  or  the  result  of  integrating  independent 
specification  and  programming  languages  such  as  the  approach  used  by  Larch  [GH93] 
and  as  exemplified  by  the  RESOLVE/Ada95  components  shown  in  Chapter  5. 

The  classification  of  software  components  into  these  four  categories  is  based  on 
Edwards’  ACTI  model  of  software  subsystems  [Edw95].  ACTI  stands  for  Abstract  and 
Concrete  Templates  and  Instances.  However,  in  the  ACTI  model,  the  term  “concrete 
instance”  refers  to  the  run-time  denotation  of  an  executable  subsystem.  In  contrast, 
we  use  the  term  “concrete  instance”  to  refer  to  the  syntactic  encoding  of  a  component 
for  which  the  run-time  semantics  may  be  modeled  as  an  ACTI  concrete  instance. 
Similarly,  we  use  the  terms  “concrete  template”,  “abstract  instance”,  and  “abstract 
template”  to  refer  to  syntactic  units  of  software  whereas  ACTI  uses  the  terms  to  refer 
to  a  denotational  semantics-based  representation  of  the  run-time  behavior  described 
by  the  corresponding  components.  The  ACTI  model  does  not  define  a  separate  unit 
corresponding  to  math  modules.  Instead,  ACTI  components  include  specification 
adornment  environments  [Edw95,  p.  85]  which  may  be  used  to  construct  components 
that  serve  the  same  purpose  as  our  math  modules. 

The  model  requires  that  every  unit  in  U  have  a  unique  unit  name.  When 
referring  to  individual  units,  we  shall  use  lower  case  identifiers  such  as  u,  m  and  Ci 
to  denote  unit  names.  A  unit’s  content  is  the  string  of  symbols  associated  with  a 
unit  name  and  encoding  a  math  module  or  a  component.  The  only  syntactic  aspect 
of  a  unit’s  content  that  is  modeled  directly  is  its  context.  The  context  of  a  unit  is 
the  finite  set  of  all  externally  defined  units  upon  which  a  unit  directly  depends. 

Any  unit  in  U  may  be  defined  directly  or  indirectly  in  terms  of  a  finite  number 
of  other  units  in  U.  If  one  unit,  say  Ui  is  defined  in  terms  of  another  unit,  say  U2, 
then  Ml  depends  on  u^.  Components  in  C  may  depend  on  math  modules  in  M  and 
other  components  in  C.  Math  modules  may  only  be  defined  in  terms  of  other  math 
modules  in  M.  In  order  for  ui  to  depend  directly  on  U2,  the  name  of  unit  U2  must 
appear  in  the  content  of  unit  Ui.  That  is,  when  referring  to  an  implementation  or 
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specification  eleiiu'iit  wliicli  ll^  does  iu)t  itself  fh'fiiu'.  ii\  must  explicitly  name  the  unit 
di'huim:  the  referenced  ehuneut.  Note  that  no  unit  (h'lu'ufls  din'ctlv  on  itself.  We 
refer  to  a  unit's  context  l)y  using  tin-  jirojc'ct ion  fnnetion  ctxj'  — )■  VfV  (where  VfV 
denotes  the  set  of  all  finite  snbst'ts  of  T)  (h'fiiH'd  as  follows: 

ctx(//)  =  {//'  G  f '  —  {//}:  n  (h'pends  directly  on  ii'}  (2.1) 

Wc  also  rerjnire  that  all  units  in  (  Ix'  vcll-fajuicfl  with  rt'sjiect  to  the  s\ntax  of 
the  language  L.  Only  well-formed  units  an'  assigiu'fl  a  meaning  as  discn.ssed  in  the 
foll'iwing  sections,  figure  2.3  dej)icts  the  h\('  syntactic  catf'gories  of  units  in  language 
L  discmserl  in  this  section. 

2.2.1  Implementation  Components 

1  he  set  C  I  of  concrete  instances  consists  of  all  possible  (nni(|n('Iy  nanu’d)  imj)l('- 
mentation  components  that  may  Ix'  t'xpn'sst'd  by  finite'  h'ngth  strings  in  some  fixt'd 
lanenage  /,.  A  concrete'  instance'  has  no  paranu'te'rs  anel  re'pre'.se'iits  a  jireigram  unit 
with  cennph'te'ly  de'fineel  ope'iatieeiis  ready  tei  inte'grate'  intei  a  setftware'  system.  For 
the'  pnrpeise'  eif  eh'seribing  ('le'UK'nts  o\’  Cl.  L  may  be  vie'we'el  as  a  ])re)gramming  lan- 
gna'ic  (angme'iite'el  Iw  a  sjee'e  ifie-at  ieeii  language)  and  element  e)f  Cl  as  im])lementation 
meielnh's.  .-\s  iieete'd  abe)\'e'.  e'Ve'iy  ('le'nx'iits  eel  Cl  must  be  H'rll-Jojitxfl  and  have  a 
we'll-eh'fine'el  me'aning.  1  hns.  e'aeh  ('le'int'nt  eif  Cl  must  be'  a  h'gal  imph'inentation 
meeflnh'  in  ae-corelance  with  the  .syntax  of  L.  While'  a  member  of  Cl  is  a  finite  string 
eif  symbeils  from  the  finite'  alphabe't  of  L.  tlu're  is  no  np])t'r  betnnd  on  its  size.  Thus 
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any  useful  L  supports  description  of  a  countably  infinite  number  of  concrete  instances 
—  the  size  of  Cl  is  A  component  providing  a  complete  data  representation  and 
fully  implemented  operations  for  manipulating  a  list  of  characters  is  an  example  of  a 
concrete  instance. 

The  set  CT  of  concrete  templates  consists  of  all  possible  (uniquely  named)  param¬ 
eterized  implementation  components  that  may  be  expressed  as  finite  length  strings 
in  L.  The  only  difference  between  the  content  of  elements  of  CT  and  Cl  is  that  an 
element  of  CT  refers  to  a  single  abstract  instance  that  serves  as  a  formal  parameter 
for  which  the  actual  parameter  is  a  concrete  instance’^.  Whereas  an  element  of  Cl 
models  a  ready-to-use  component  that  may  be  incorporated  directly  into  a  larger 
sj'stem,  an  element  of  CT  models  a  component  that  must  be  instantiated  in  order  to 
generate  a  concrete  instance.  An  implementation  of  a  list  parameterized  by  the  type 
of  elements  contained  within  the  list  is  an  example  of  a  concrete  template. 

The  motivation  for  modeling  concrete  instances  is  clear  —  they  represent  the 
modules  that  make  up  a  fully  integrated  component-based  software  system.  Concrete 
templates  also  play  an  essential  role  in  the  model.  They  provide  direct  support  for 
substitutability  and  thus  are  useful  for  more  than  just  the  generalization  of  families 
of  related  implementations.  We  discuss  the  primary  role  of  concrete  templates  in 
Section  2.4.2. 


2.2.2  Specification  Components 

In  previous  sections,  we  have  referred  to  a  behavioral  interface  specification  as 
if  it  were  different-in-kind  from  a  software  component.  With  physical  systems,  in¬ 
terface  specifications  and  the  physical  components  that  conform  to  them  do  tend 
to  be  markedl}'^  different.  For  example,  we  are  unlikely  to  confuse  light  bulbs  and 
light  bulb  sockets  with  the  specification  document  describing  their  standard  inter¬ 
face.  The  situation  is  different,  however,  with  software.  Software  components  are 
symbolic  descriptions  of  possible  computer  behavior.  A  software  interface  specifica¬ 
tion  that  describes  what  computer  behavior  is  required  and  a  software  component 
that  describes  how  some  computer  behavior  is  achieved  are  quite  similar  in  nature. 
Both  play  important  roles  as  parts  (components)  of  a  complete  description  of  how  a 
component-based  software  system  may  be  constructed  or  has  been  constructed.  To 
reflect  the  important  role  of  software  interface  specifications,  we  include  in  our  def¬ 
inition  of  “software  component”  both  implementation  components,  members  of  Cl 
and  CT^  and  specification-only  components,  members  of  AI  and  AT. 

The  set  AI  of  abstract  instances  consists  of  all  possible  (uniquely  named)  spec¬ 
ification  components  that  may  be  expressed  by  finite  length  strings  in  some  fixed 

^We  limit  a  template  to  a  single  parameter  for  modeling  convenience.  However,  multiple  para¬ 
metric  dependencies  may  be  modeled  by  a  single  formal  parameter  where  the  actual  parameter  is  a 
single  concrete  instance  that  satisfies  all  of  the  requirements  expressed  by  what  would  otherwise  be 
se^•eral  parameters. 
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Iniiminuf'  L.  An  ahstract  instanc‘('  has  no  ]>arainrt('rs  and  ro])r(\s(Mits  a  sot  of  r('ad\'- 
to-nsf*  l)f’lia\‘ioi'al  intc'rfaon  S])fH’ifications.  I*or  thr  pnrposns  of  df\s(‘ril)ing  (df^iirnts 
of  AI .  L  may  Ix^  vicnvc'd  as  a  spocifioation  lanp;uaf;('  augiiKnitcnl  hy  a  ])rogramniing 
lanynauf'  in  which  tlu'  syntactic  (structural)  intc'rfacc  of  an  ini])I(Mn('ntation  iiioduh' 
may  he  dcdinc'd  indcjaMKhuit ly  from  its  implcuncntat ion.  Each  element  of  Al  is  a 
wc‘ll-f( )i*ined  s])f'c‘ificat ion  in  accoi*(lanc('  \\'ith  tlu'  syntax  of  L.  For  anv  nsc'fnl  L,  the 
si/c'  of  AI  is  K(,.  An  ('hmunit  of  AI  s|)fx*ifi('s  a  behavioral  intcuiacc'  that  (h'scrilx's 
tlu‘  extf'rnall\‘  visible'  striicUure  (sit^nature)  and  associatc'd  opc'ration  Ix'haviors  that 
(‘ciiiformine  concrc'te  instance's  must  provide'.  Thus,  the'  s])e'cification  elements  of  L 
shniild  be'  siiffie-iently  ex])re'ssive  to  de'se-ribe  any  behaviors  of  inte'rerst  that  may  be  ce)n- 
strueUf'rl  with  the'  imple'nu'iit atie)n  f'le'nu'iits  of  L.  L  mi,L»;ht  ne'C'd  to  l)e'  \'('ry  ])ow('rful  in 
orelf'r  to  spe'cifv,  perhaps  neui-de'te'rniinistically,  the  functional  and  te'inporal  asjx'cts 
of  be'haviors  (‘xhibite'd  by  ce)j]i])!('x  imple'inent ations.  In  general.  L  may  need  to  n'lv 
(Ui  hiizlx'r-oreh'r  louics  anrl  a  wiele'  variety  of  math('mati(*al  and  a])plication  doniain- 
S])e'eufie*  tlu'orie's.  Software'  si)f'e‘ifie‘at ieui  lan”uaRes  such  as  Z,  \’DM.  the  Larch  Shared 
Lanuuaue',  anel  the'  spe'e-ilicatie)n  sub-languaRc  of  RESOIA’E  are  all  possible'  candi- 
flate's  for  the'  spf'cificat ie)n  ne)tatie)n  of  L.  A  component  s])e(*ifving  the'  sip;natures  and 
Ix'havior  e)f  o])e'rat ie)ns  manipulat  in,u,  a  list  of  characte'rs  (without  de'seuibiiyu;  the  list 
im])lf'me'ntat ion )  is  an  exam])le'  of  an  abstraeU  instanc'e. 

The'  se't  AI  of  abstract  te*m])lat('s  consists  of  all  possible'  (uni(|ueh'  nanu'd)  ])a- 
rame't e'ri/e'fl  spe'e*ifie‘atie)n  ce)m])one'nt s  that  may  be  ('xpressed  as  finite  le'iigth  strings 
in  L.  The'  re'lationshi])  be'twec'ii  ('le'inents  of  AI  and  e'h'inents  of  AT  is  analo,e,oiis  to 
the'  re'lationshi])  be'twe'e'ii  ('le'nu'iits  of  CT  and  Cl  .  The'  only  diffe'rence  Ix'tw'e'C'ii  the' 
contf'iiT  of  c'le'me'iits  of /17  aiul  AI  is  that  an  ('le'iiu'nt  of /17'  refers  te)  one  abstract  in- 
statie'e'  that  se'rve's  as  a  formal  ])arame'te'r  fe)i*  whi(*h  the  actual  parame'te'i*  is  a  concrete' 
instane*e'.  An  eh'ine'nt  of  A7  me>de'ls  a  fj,e'ne'rie'  l)eha\’ioral  inte'rfae’c'  that  must  be  in- 
stantiatf'd  in  e)reler  to  ^tuierate*  an  abstraeU  instance.  A  specification  of  the'  signature's 
anel  be'havior  e)f  operatie)ns  manipulating  a  list  that  is  parameteri/ed  by  tlu'  tyi)e  of 
eh'inents  ce)ntaine'd  in  the'  list  is  an  example'  of  an  abstract  tem])late. 

As  a  spe'c-ification  inele'i)ende'nt  from  i)articular  imple'mentatie)ns.  an  abstraeU  in- 
stane’e*  niay  se'rvf'  twe)  cl()se'ly  re'late'd  but  distinct  role's.  First,  an  abstract  instanc*(' 
may  be'  use'd  to  dese*ribe'  the'  be'havie)r  of  one  or  me)re'  conen'te'  instances  which  con- 
f(»nn  te)  it.  1  his  role’ is  (h'pic't  e'd  in  the'  botte)m  half  e)f  F  iguix' 2.2.  Se'cond,  an  abstract 
in>tane-e'  may  Ix'  use'el  te)  de'sciibe'  the’  Ix'lundoral  re'Ciuire'nu'iits  of  a  ce)m])one'nt  at  an 
alxtraet.  im])le'nient at ion-inde'pende'nt  le've'b  Jhis  re)le'  is  de'picted  in  the  top  half  of 
Fiuure'  2.2.  An  abstraeu  template'  is  primarily  a  convenient  way  of  generali/ing  a  set 
of  e  lose'ly  re'late'd  abstract  instanc'C'S. 

Maintaining  s])ee‘ifie*at ie)n  ce)ni])e)nents  ale)ngsid('  imple'inentat ie)n  (‘omi)e)nents  al¬ 
low  >  the'iii  te)  be'  use'd  foi'  structural  (syntae'tic)  conformance'  che'cking  at  ce)mpoiient 
(‘e)mi)ilation  and  inte'gration  time.  Spe'cificat ion  components  may  also  be  used  for 
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behavioral  (semantic)  conformance  checking  during  the  process  of  certifying  that  a 
particular  implementation  conforms  to  a  specification,  when  such  a  claim  is  made. 


2.2.3  Math  Theory  Modules 

The  role  of  mathematical  theory  modules  is  to  encode  mathematical  objects  for 
use  in  modeling  program  behavior.  We  rely  on  set  theory  to  provide  a  foundation 
upon  which  arbitrarily  complex  state  spaces  and  transitions  may  be  built  to  math¬ 
ematically  model  program  behavior.  Enderton  describes  how  mathematical  objects 
such  as  numbers  (natural,  integer,  rational,  and  real  numbers),  tuples,  functions, 
and  relations  may  be  represented  with  sets  [End77].  For  example,  logicians  typically 
represent  the  set  of  natural  numbers  {0, 1, 2, . . .}  by  the  set  {0,  {0},  {0,  {0}}, . . .}  in 
which  the  empty  set  represents  zero  and  each  of  the  other  natural  numbers  is  repre¬ 
sented  by  the  set  of  natural  numbers  that  precede  it.  Using  constructive  definitions 
such  as  this,  it  is  possible  to  define  the  domains  of  mathematical  theories  (such  as 
number  theory  for  naturals)  and  then  prove  the  axioms  of  those  theories  using  only 
the  axioms  of  set  theory^. 

Mathematical  theories  and  their  associated  domains,  operators  (functions  and  re¬ 
lations  over  the  domain),  and  defining  axioms  are  encoded  in  math  modules  (elements 
of  M)  for  use  by  components  and  other  math  modules.  We  adopt  the  terminology 
defined  in  [HLOW94]  and  call  the  domain  associated  with  a  theory  a  math  type  (oth¬ 
ers  use  the  term  sort)  and  functions  and  predicates  associated  with  a  theory  math 
operations.  The  motivation  for  this  terminology  is  to  draw^  an  analogy  between  math 
types  and  operations  and  program  types  and  operations.  The  meaning  encoded  by 
a  math  module  is  derived  from  an  interpretation  of  the  math  type  and  math  oper¬ 
ations  that  it  defines.  An  interpretation  function  I  maps  the  math  type  and  math 
operations  defined  by  each  math  module  to  representative  sets.  The  domain  of  I  is 
the  set  of  math  modules  M.  The  range  of  I  is  a  collection  of  sets  U,  large  enough  to 
model  any  program  behaviors  of  interest®. 

For  example,  I  might  map  the  natural  number  math  type  defined  in  a  math 
module  for  number  theory  to  the  set  {0,  {0},  {0,  {0}},  •  •  •},  the  constant  math  op¬ 
eration  0  (zero)  to  0,  a  math  operation  for  successor  to  the  set  of  ordered  pairs 
{(0, 1),  (1, 2), . . .}  (with  pairs  encoded  as  sets),  and  so  forth.  The  interpretation  of 
this  theory,  as  conveyed  by  axioms  stated  in  the  math  module,  is  that  elements  of 
the  math  type  represent  (the  mathematical  concept  of)  natural  numbers.  Of  course 
(infinitely)  many  other  sets  in  V  could  be  used  to  represent  natural  numbers.  In 
defining  the  role  of  I  we  just  require  that  it  map  each  mathematical  object  defined 

‘‘Zermelo-Fraenkel  set  theor}'  with  the  Axiom  of  Choice  (ZFC)  provides  widely-accepted  axioms 
suitable  for  defining  much  of  mathematics  in  terms  of  set  theory  [End77,  p.  253]. 

®  A  collection  V  suitably  large  for  any  modeling  need  is  the  proper  class  of  all  sets  [End77,  p.  210] 
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l>y  a  math  module  to  some  s('t  in  \  for  which  the  axioms  statt'd  in  the  math  module 
can  1)('  jnstifierl.  ultimately  in  tt'rms  of  the  axioms  of  set  tln'orv. 

I  sill"  the  model-liased  specification  a|)proach.  each  pnxjrinn  tjipc  from  which  pro¬ 
gram  ohjects  (varialiles)  may  Ix'  declari'd  is  modeled  hy  a  math  type.  Tin'  semantics  of 
L  fixes  the  math  models  for  atiy  iirogram  ly])es  huill  in  to  /,.  Comtnon  built-in  types 
for  proyramtnin,"  lan"ua"e.s  include  Ifoolean.  integer,  character,  atid  floating  jioint 
scalar  type's  as  well  as  typ('  constructfus  for  static  data  structure's  such  as  n'cords 
ainl  arra\s  anel  for  dynamic  point er-base'd  structures.  The  se’imintics  of  L  also  must 
eh'fine  the'  nn'aning  of  built-in  control  strue  ture's  such  as  state'iuent  se'cnie'uces.  condi¬ 
tional  state'iiK'nts.  leieijis.  anel  ])roe’('elure  atiel  function  calls  which  ajipe'ar  in  e'oncrete' 
in^tane-('s  ainl  eeun'i'cte’  template's.  When  a  cotniioiu'nt  (a  member  eif  C)  de'fint's  a 
(neui-bnilt-in)  program  tyjie'.  the'  program  tyjx'  is  asseiciate'el  with  a  math  tyiie  (eh'- 
fined  in  a  math  menlule')  that  serve's  as  the  be'havieiral  moeh'l  feir  the'  program  type'. 
The'  math  e)])e'rations  ele'fiiu'el  by  the'  axioms  anel  the'orems  eif  a  the'ory  asseiciate'd  with 
the'  math  tyjie'  are'  usf'd  tei  de'se  ribe'  the'  be'havieir  of  ])rogram  operatiems  on  eibje'e'ts  of 
the-  preegram  type'. 

2.2.4  Component  Behavior 

I  p  to  this  |)oint  we'  have'  use'el  phrases  sue-h  as  "e'omjiute'r  belnnior'  .  ’'In'lnwieirs 
imph'ine'ntf'el  by  a  ceemjione'nt  .  and  "be'haviors  speeifie'el  by  a  ceimpeine'iit  withemt 
afte'mi>ting  to  de'fine'  the'  te'rm  ••be-havieir" .  Tei  moele'l  eonfbrmane-e  tei  be'havieiral  inter- 
fae-e  s]ie'cifie  at  ieiiis.  we'  must  ine'lude'  semie  ceincept  of  e  eimimter  behavior  in  the  moele'l. 
In  oreh'r  tei  make'  the'  moele'l  as  latigiiagf'-inele'jienele'nt  as  peissible'.  heiweve'r.  the'  moele'l 
e  anneit  be'  teio  s])e'e  ifie-  abeiut  the  e'xae  t  feirin  of  meiele'le'el  be'haviors. 

I  In'  stanelarel  aiipreiae-h  tei  meieh'ling  eeimpute'r  behavieir  is  tei  ele'fine  a  colle'e  tiem 
eif  state's  anel  transitions  be'twe'cn  tlnise  state's.  state'  re'])re'.sents  the'  status  between 
transitieins  eif  the'  physieal  system  (a  eomputer  eir  e'eimpute'r-e'ontreille'el  .system)  that 
earrie'>  eiiit  eiperatiems  ele'seribe'el  by  seiftware.  Tlie  transitieins  freim  state'  to  state' 
re'pre'.'.ent  the  be'havieir  eif  the  jihysieal  .syste'in  anel  thus  the  behavieir  ele'seribe'el  by 
the'  seiftware'.  Hie'  se-mantie's  of  a  ])reigramming  language  maps  well-feirme'el  syntae'tic 
e'le'ments  eif  the'  language'  tei  se'ts  of  trtmsitieins  in  the  state'  sjiae-e'.  The  ele'finitiein  eif 
the-  state,^.  which  may  be-  expre'sse'el  in  terms  eif  an  abstrae-t  mae-hine  rather  than  a 
spe'e  ific  e'ompnte'r.  ele'te'rmine's  the'  e'xte'iit  tei  whieT  eliflere'iit  physie'al  lie'havieirs  can  be' 
elist imruishe'el  by  the'  se'inantie's  eif  a  ]ireigrammitig  language'. 

I  he'  aiiproae-h  we'  use'  tei  e-haracte'ii/e  the'  semantie-s  eif  seiftware  e-eimpeinents  is  to 
assume'  a  traelitional  (ei]ie'ratieinal  eir  ele'initatieinal)  semantie's  feir  e'eine-re'te'  instane-es 
anel  tin'll  ele'fine'  the'  semantie  s  eif  ele'ine'nts  eif  A1 .  CT.  anel  AT  in  te'rms  eif  the'  .se'inantie-s 
eif  e'h'ine'nts  eif  C  I .  Sine'e'  a  e'eine'ie'te'  instane'e'  has  nei  unre'seilve'el  exte'i'iial  ele'iienele'ne'ies. 
the'  semanrie  eif  a  e'onerete'  instanee'  that  imple'inents  a  single  eiperatiein  may  be'  tre'ate'el 
like'  the'  se'inantie-s  of  a  single'  e'limple-te'  preigram.  Tin'  semantics  eif  a  eeine’iete'  insttuu'e 
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that  implements  more  than  one  operation  may  be  treated  as  potentially  interacting 
programs  that  may  manipulate  a  common  state. 

We  use  the  semantic  function  S  to  describe  the  mapping  of  software  components 
(all  members  of  C)  to  a  set-based  representation  in  V.  Since  the  meaning  of  each 
program  type  used  within  components  is  determined  by  its  associated  mathematical 
model,  S  is  determined  in  large  part  by  the  mappings  of  I.  For  example,  say  com¬ 
ponent  ce  Cl  refers  to  program  type  tp  which  is  modeled  by  math  type  T M.  Then 
within  the  representation  of  <S(c),  objects  of  program  type  t  will  be  represented  by 
the  set  given  by  XiTM).  Since  all  elements  of  C  must  be  well-formed  components, 
S  is  a  total  function  with  domain  C.  However,  the  range  of  S  is  likely  to  be  only  a 
small  portion  of  V  which  corresponds  to  sets  that  model  program  behavior. 

We  model  the  behavior  of  a  concrete  instance  by  a  single  element  of  the  collection 
B  of  abstract  behaviors  which  is  a  subset  of  V.  The  semantic  function  S  maps 
each  element  of  Cl  to  an  element  of  B.  For  c  G  Cl,  S{c)  represents  the  meaning 
(semantics)  of  c  in  the  model  of  behavior  used  to  define  B.  The  set  <S(c)  represents  an 
aggregation  of  lower-level  semantic  functions  yielding  the  meaning  of  each  operation 
defined  in  c,  which  may  be  defined  in  terms  of  the  operations  in  other  concrete 
instances  upon  which  c  depends,  all  of  which  are  ultimately  defined  in  terms  of  1  and 
the  semantics  of  elements  of  L. 

The  nature  of  an  element  of  B  depends  upon  the  type  of  semantics  used  to  define 
L.  Consider  a  concrete  instance  c  e  Cl  which  implements  and  provides  for  use  to 
other  components  three  operations:  Oi,  02,  and  03.  Then  the  essence  of  <S(c)  E  B  is 
the  set  {<S(,(oi),<So(o2),«5>o(o3)}  where  So  defines  the  semantics  of  program  operations. 
S(c)  might  also  incorporate  specification  information  to  aid  in  formal  verification.  If 
S  defines  the  meaning  of  strings  of  L  in  terms  of  a  denotational  semantics,  then  5o(oi) 
would  correspond  to  a  partial  function  from  states  to  states.  The  domain  of  the  func¬ 
tion  would  represent  all  states  in  which  the  operation  could  be  applied  meaningfully. 
Application  of  the  function  would  model  the  change  in  state  resulting  from  execution 
of  oi-  If  5  defines  the  meanings  of  strings  of  L  in  terms  of  an  operational  semantics, 
then  5o(oi)  would  correspond  to  a  set  of  sequences  of  states.  Each  sequence  would 
correspond  to  all  intermediate  states  along  one  possible  “execution  path”  through  Oi. 
The  space  of  ACTI  concrete  instances  [Edw95,  p.  66-77]  is  one  way  in  which  B  might 
be  defined  using  a  denotational  semantics  approach. 

To  keep  the  model  as  simple  as  possible,  we  define  the  semantics  of  abstract 
instances  extensionally.  We  define  the  meaning  of  an  abstract  instance  as  the  set 
of  meanings  of  all  concrete  instances  which  conform  to  the  behavior  specified  by 
the  abstract  instance.  Using  this  definition,  the  range  of  the  semantic  function  S 
with  domain  restricted  to  AI  is  the  power  set  of  B,  VB  —  the  set  of  all  subsets  of 
B.  A  specification  a  E  AI  may  be  thought  of  as  stating  a  behavioral  requirement. 
Each  behavior  in  B  either  does  or  does  not  satisfy  that  requirement.  S  maps  each 
specification  in  AI  to  the  set  of  all  behaviors  in  B  that  satisfy  the  specified  behavioral 
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2.1:  Iin])l(Mnontati()ns.  Sprcific^at ions,  and  Bcdundors 


r('f jiiimiunn .  It  is  ])ossil)l('  foi'  a  spc'cificat ion  r/  €  AI  to  stat('  a  rrcjiiirtnnont  that  no 
l)(’liavior>  in  B  satisfy.  In  this  casr.  S{(i)  —  0.  Fi^L!;iir('  2.4  (l('])icts  all  of  tlu'  spaces 
in  tlif‘  inod<4  ('X(‘0])t  for  tf'ni])lat(‘  conipoin'nts  and  tlndr  associatcxl  st'inantics.  Tin' 
sfMiiantics  of  t(nn])lat('  coniponents  will  Ix'  disf‘nss('d  in  Sc'ction  2.4.2. 


Defining  tli(‘  sc'inaiitics  of  a  lan^^inyyc'  L  to  th('  d(\u,i'ee  nc'cc'ssarv  to  formally  justify 
that  an  f'h'inent  of  TV  ind(Hxl  conforms  to  an  (dcmicnt  of  ,4/  is  a  significant  undertak¬ 
ing.  hurt hermoif',  once  <5  and  B  hav('  Ix'en  (hdiinxl  for  a  spc'cific  language^  L,  \\w  task 
of  Vf'rifying  wlnuln'r  soni(‘  c  £  Cl  is  correct  with  n'spect  to  some  r/  G  AI  nun*  1)(^  ex- 
trf'inely  diflicult  aiul  t  In'orcn  ically  iui|)ossil)l(' in  some' cases.  Xe've'rtlu'h’ss,  it  is  j)ossil)l(' 
to  formally  rh'fine'  tlu'  sf'mantics  of  programming  language's  supporting  comj)onent- 
ha^e'd  software'  ('ngiiu'ering  ami  te)  formali/e’  the'  rule's  for  justifying  the'  e‘e)rre(‘tn('ss  of 
implf'inentations  with  re'sjx'en  \n  he'havioral  six'cifications  [Kre)S8.  He'ynoi. 


2.3  Conformance  Relationships 

As  explained  in  Section  2.1,  in  order  to  support  component-level  maintenance, 
we  need  to  address  the  issue  of  an  implerrientation’s  conformance  to  a  behavioral 
interface  specification.  We  would  like  to  be  able  to  conclude  that  if  an  implementation 
“conforms  to”  a  specification,  then  that  implementation  may  be  used  wherever  there 
is  a  requirement  for  the  behavior  described  by  the  specification.  In  this  section  we 
define  three  component  conformance  relations.  Section  2.3.1  defines  the  fundamental 
conformance  relation  between  concrete  instances  and  abstract  instances.  Section  2.3.2 
defines  a  conformance  relation  between  two  abstract  instances. 


2.3.1  Implementation- To-Specification  Conformance 

Informally  stated,  if  c  G  CJ  conforms  to  a  G  AI,  then  c  must  fully  and  correctly 
implement  all  behavior  described  by  a.  However,  c  may  also  implement  behavior 
not  specified  by  a  as  long  as  all  requirements  of  a  are  satisfied  by  c.  While  this 
conformance  relation  is  stated  in  terms  of  c  and  a  (strings  of  symbols),  it  is  the 
structure  and  behavior  implemented  by  c  that  must  conform  to  the  structure  and 
behavior  specified  by  a.  Using  the  semantic  function  S  and  the  collection  of  modeled 
behaviors  B  described  in  Section  2.2.4,  we  define  the  conformance  relation  imps:C'/  x 
AL  as  follows; 


imps(c,  a)  =  <S(c)  G  S{a)  (2.2) 

The  predicate  imps(c,  a)  may  be  read  as  “component  c  implements  component 
a”.  Figure  2.5  depicts  this  relationship  with  a  solid  arrow  from  implementation  c  to 
specification  a.  The  behavior  implemented  by  c,  <S(c),  is  represented  by  the  point 
b  e  B.  The  set  of  behaviors  specified  by  a,  <S(a),  is  depicted  by  the  single  point  in 
VB  and  by  the  dashed  gray  oval  in  B.  The  double-ended  gray  arrow  between  B  and 
TB  points  to  both  representations  of  this  set.  Since,  in  this  example,  c  implements 
a,  5  is  a  member  of  the  set  «S(a). 

imps  is  a  many-to-many  relation.  Just  as  there  are  many  different  ways  to  imple¬ 
ment  a  given  specification,  there  may  be  many  different  ways  to  abstractly  describe 
behavior  provided  by  a  single  implementation.  Implementations  conforming  to  the 
same  specification  may  vary  in  ways  that  do  not  affect  the  behavior  implemented 
(e.g.,  the  number  of  embedded  comments,  which  might  affect  maintainability  but  not 
the  run-time  behavior) .  Since  a  conforming  concrete  instance  may  describe  behavior 
not  required  by  an  abstract  instance,  implementations  conforming  to  a  common  spec¬ 
ification  also  may  differ  with  respect  to  their  implementations  of  these  “additional” 
behaviors.  Conforming  concrete  instances  also  may  implement  non-deterministically 
specified  behaviors  in  ways  that  produce  significantly  different  behaviors  and  yet  still 
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H, Idlin'  2..*):  Jhr  imps  Hc'lntion 


('()iif( >i'iii  to  tli(‘  ahstract  instaiioc'.  J  lu'  possihilit ios  ar{'  analo.^otis  for  multiple'  sjx'oifi- 
cations  that  arn'iirate'ly  charact  f'ri/r  a  siti,u;l{'  iiii])I('nu'nt  at  ion.  Diflrroiit  s])('cifications 
i<*  whifli  i\  sinyh'  iiii])l('nK'ntatioii  ronfonns  may  ho  trivially  diflVre'iit  syntactic'  vari¬ 
ants  that  s])('cify  the  sanu'  Ix'havior.  Diflc'rc'ut  spc'cafications  may  sp('cif\'  disjoint 
sill )-l )clia\‘iors  of  tlu'  total  Ix'luu'ior  ini])l('m('nt('d  hy  a  sin,u;l('  conforming  im])l('mcnta- 
tion.  finally,  difien'cnit  spc'cifications  may  dc'scrilx'  the'  same  im])l('m('nt('d  Ix'lnn'ior  in 
snl)stanri\-('ly  diflcrenit  ways. 

If  impsfr.  r/)  holds,  tin'll  tln'rc'  must  Ix'  some'  h'gitimatc'  way  of  ('X])laining  hoir  c 
iinph'incnts  a.  Such  an  '‘('Xplanation  must  addrc'ss  how  tin'  languagc-spe'cific  struc¬ 
tural  (syntacti(')  n'cjuirc'nn'uts  off/  may  Ix'  satisfied  hy  tin'  structure'  of  c  and  how  tin' 
hf'havioral  (sf'inantic)  rc'cjuirc'iin'nts  of  f/  may  Ix'  satisfic'd  hy  the'  o])C'rations  dc'finc'd  hy 
( .  \\  hih'  pro\'iding  an  c'xplanation  of  how  c  conforms  to  a  is  essc'iitial  for  justifying 
a  c'laini  that  impsfc.r/).  suc'h  a  claim  is  c'ithc'r  valid  or  inwdicl  inclc'i>enclc'nt  of  anv 
particular  c'Xplanation. 


Finallv.  note'  that  impsfc.r/)  doc's  not  imply  that  r/  G  ctx(c).  Tliat  is,  an  imi)le'- 
nn'iitation  ne'C'd  not  refe'r  to  a  si)C'c*ific*at ion  that  it  im])Ic'ments.  From  a  de'sign  and 
iin])le'nn'ntat  ion  ])erspc'c't  ivc'.  tlic're  are  both  advantage's  and  disadvantage's  to  having 
an  iinple'nn'Ut  at  ion  cou])Ie*eI  to  a  spec'ific'at  ion  to  which  it  ce)nfe)rms.  We  will  disc'iiss 
thc'sf'  issue's  in  Se'eUion  1.3. 


Figure  2.6:  Specification  Conformance  And  Subsets 


2.3.2  Specification  Extension 

We  now  consider  a  conformance  relationship  between  two  specifications  in  AI. 
As  discussed  above,  for  imps(c,  a)  to  hold,  all  behavior  described  by  a  must  be  im¬ 
plemented  by  c,  but  c  may  also  implement  additional  behavior  left  unspecified  by 
a.  Thus  c  may  implement  a  and  also  implement  other  specifications  that  describe 
more  or  fewer  requirements  on  implementations  than  a.  Consider  a  specification, 
say  Oi,  that  places  certain  structural  and  behavioral  requirements  on  all  conforming 
implementations.  Now  assume  another  specification,  say  02,  specifies  the  same  be¬ 
havior  as  ai ,  plus  some  additional  behavior  not  specified  by  oi .  In  this  situation  any 
concrete  instance  that  implements  02  should  also  implement  ai,  but  there  may  be 
implementations  of  Gi  that  do  not  implement  02.  Figure  2.6  depicts  this  situation. 

On  the  left  side  of  Figure  2.6,  the  solid  arrows  from  elements  of  Cl  to  elements  of 
AI  represent  pairs  in  the  imps  relationship.  That  is,  Ci  implements  Oi  and  both  Ci 
and  C2  implement  02,  but  Ci  does  not  implement  02.  The  property  that  all  concrete 
instances  implementing  also  implement  Gi  (in  this  example)  is  depicted  on  the  right 
side  of  Figure  2.6.  The  dashed  gray  ovals  inside  of  B  represent  subsets  of  B  and  the 
double-ended  gray  arrows  between  B  and  V{B)  point  to  two  different  representations 
of  the  same  set  of  behaviors.  The  larger  oval  represents  <S(ai),  the  set  of  all  behaviors 
that  satisfy  the  behavioral  requirement  specified  by  Oi.  The  smaller  oval  represents 
*5(02),  the  set  of  all  behaviors  that  satisfy  the  behavioral  requirement  specified  by  02. 
In  the  figure,  <5(02)  is  depicted  as  a  subset  of  5(ai).  Therefore,  all  concrete  instances 
that  implement  the  behavior  specified  by  02  (such  as  C2)  also  implement  the  behavior 
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I-'i,t;urc  2.7:  'J  Ik'  exts  H('lati()ii 


si)('(ific(l  hy  (l^.  Mon'  siiui)!y  statcfl,  all  concia'tc  iiist ancf'.s  that  iinj)l('iii('nt  Oj  also 
iiii])l('nK'iit  r/]. 

In  tl)('  sii nation  dcscrihofl  abovr.  \vc  may  say  that  s])('cifi(ation  c;-..  •■conforms  to" 
specification  r/i.  This  notion  of  confornmticc  is  sitnihir  to  that  of  hdiavinwl  siihtiip'nui 
I.M  D  !  .  We  define  t his  rt'lat  ion  l)('t\v<'('n  two  s])ecifications.  exts:.  1/  x  AI .  as  follows: 

ext.s(f/.,.  n, )  HE  S{a-2)  C  S(ai)  (2. .‘I) 

I  lie  predicate  extsfoj.ri])  may  Ix'  read  as  ’'six'cification  r/j  ('xft'iids  specification 
o;  .  I-i.mire  2.7  snintnarizes  all  of  llx'  infornmt ion  ex])licitly  shown  in  Figiin'  2.0. 
I  he  da-'lx'fl  arrow  fiom  (ij  to  dejiicts  the  exts  rehit  ionship  hetwei'ii  tlx'.se  two 
specificat  ions. 

If  extsfoj.  c/i )  holds,  then  the  behavioral  recpiirements  s]x'cified  bv  a  ,  may  be 
viewerl  as  an  extensioti  of  the  Ix'havioral  rec|tiir('ments  spt'cified  by  r/|.  This  dot's  tint 
mean  that  tht'  (symbolic)  contt'iit  of  r/j  is  ati  extension  of  the  contt'nt  of  fi].  although 
that  nix/hf  be  the  case.  .Inst  tis  c  net'tl  not  rt'ft'r  to  a  for  imps(c,  ri)  to  liold.  (i  t  need 
not  refer  to  Oj  in  ordt-r  for  exts(t/_,.  r/, )  to  liold.  Xevt'i  t helt'ss.  in  order  to  justify  tliat 
extsft/j.  n, )  holtF.  then'  must  Ix'  some  way  of  t'xplaining  hair  the  Ix'havior  specifietl 
by  ty.  covers  all  of  the  behavior  spt'cifit'd  by  n|. 

I  he  exts  rehition  is  reflexivt'  (any  specification  extends  itself)  ami  tratisitive.  It 
is  not.  liowevt'r.  atit isymnx't ric  (as  is  snbst't  inchision)  since  two  diffnruf  specifica¬ 
tion  comjiom'nts  may  sjx'cify  identical  Ix'havioral  recinirements  and  thus  extend  each 
other. 

■A  useful  property  that  follows  dlri'ctly  from  the  ch'finitions  of  imps  and  exts  is: 

2s; 


imps(c,  0.2)  A  exts(a2,  ai)  ->  imps(c,  ai)  (2.4) 

The  imps  relationship  between  C2  and  Oi  shown  explicitly  in  Figure  2.6  is  not 
shown  in  Figure  2.7,  but  follows  immediately  from  the  above  property. 

There  are  three  basic  ways  in  which  the  behavior  of  a  specification  component 
might  be  extended:  specialization,  generalization,  and  augmentation.  If  02  strengthens 
the  post-conditions  of  one  or  more  of  the  operations  specified  by  ai  and  exts(a2,ai), 
then  02  specializes  Ui .  If  02  weakens  the  pre-conditions  of  one  or  more  of  the  operations 
specified  by  a\  and  exts(a2,ai),  then  02  generalizes  oi.  If  G2  specifies  operations  not 
specified  by  ai  and  exts(o2,  then  a2  augments  Oi.  Any  combination  of  these  three 
forms  of  extension  (including  none  of  them)  may  apply  to  two  specifications  related 
by  the  exts  relation. 

As  a  simple  example  of  these  three  forms  of  extension,  consider  the  behavioral 
interface  specification  for  a  bounded  integer  bag  with  two  operations.  Insert  and 
Remove,  and  a  maximum  size  of  10  integers®.  A  bag  is  like  a  set  except  that  a  bag 
may  contain  more  than  one  occurrence  of  the  same  element.  The  pre-condition  for 
Insert  would  require  that  the  bag  contain  fewer  than  10  integers.  The  post-condition 
of  Insert  would  require  that  the  bag  contents  after  completion  of  the  operation  be 
the  same  as  that  beforehand,  except  that  it  should  contain  an  additional  integer  of 
the  value  inserted.  The  pre-condition  for  Remove  would  require  that  the  bag  contain 
at  least  one  integer.  The  post-condition  of  Remove  would  require  that  the  contents 
of  the  bag  after  completion  of  the  operation  be  the  same  as  that  before  hand,  except 
that  it  should  contain  one  less  integer  of  the  value  removed  —  some  integer  contained 
in  the  bag  prior  to  execution  of  the  Remove  operation.  This  is  a  non-deterministic 
specification  in  that  it  does  not  specify  which  element  of  the  bag  is  removed. 

One  specialization  of  this  bag  specification  would  be  a  specification  that  requires 
integers  to  be  removed  in  a  particular  order  relative  to  their  insertion  order  or  value. 
For  example,  a  bounded  integer  stack  specification  might  specify  behavior  identical 
to  that  specified  by  the  bag  except  that  the  value  of  the  integer  removed  must  be  the 
same  as  the  value  of  the  integer  most  recently  inserted.  Thus  the  post-condition  on 
the  stack  operation  corresponding  to  Remove  would  place  a  compatible,  but  stronger 
requirement  than  that  of  the  bag  on  all  conforming  implementations.  A  generalization 
of  the  bag  specification  would  be  one  that  requires  the  same  behavior  except  that  the 
bag  may  hold  up  to  20  integers.  In  this  case,  the  pre-condition  for  the  operation 
corresponding  to  Insert  would  place  a  compatible,  but  w'eaker  requirement  on  all 
conforming  implementations.  Finally  an  augmentation  of  the  bag  specification  might 
specify  the  same  requirements  except  that  it  also  requires  an  additional  operation  that 
returns  the  number  of  elements  currently  in  the  bag.  In  each  of  these  three  examples, 

®The  bag  specification  described  here  was  selected  for  simplicity  and  should  not  be  interpreted 
as  a  good  interface  design. 
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<iny  iniplf'incntjition  tliat  .satis{i(>s  tlu'  nHitiin'iiirnts  of  tli('  ('xtc'nclcfl  sjx’cification  also 
satisfif's  the  r(‘f|iiir('iiif'iits  of  llu'  original  hag  sjx'cificatioii. 

As  (iisciissf’fl  in  Srction  2.1.].  a  coininon  n'ason  for  clianging  tlx'  Ix'havior  of  a 
software  systf'in  is  to  arid  ix'w  finx-tionalily.  As  \\v  disctiss  in  Sr'ction  3..').  th(>  atig- 
II tent  at  ion  form  of  sjir’cificat  ion  extr'iision  is  pari  ictilarly  tisrfttl  for  inodr’Iing  (’xtr'iisions 
to  coinponr'nt  functionality. 

2.4  Dependency  Relationships 

1  he  three  conforitianee  ri'lations  (h'fined  in  Sc'ction  2.3.  imps.  exts.  and  exti.  are 
definerl  in  terms  of  the  sematitie  iiroperties  of  components.  These  ndations  morh'l 
ti-rdnl  hehavioral  rr'Iationships  Ix'iwr’im  components.  TIk'  fixed  d('])endency  rrdation 
(le.-'Ciihcd  in  Section  2.-1. 1  is  riefitied  in  tr'rms  of  t hr' synl actic  proper! ies  of  comjxinents 
anti  i>  com])letely  orthogonal  to  tlx'  cotiformance  rr'lations.  This  rr'lationship  inoch'ls 
the  tisnal  notion  of  component  coupling  applir'd  to  both  implementation  and  spr-cifica- 
tion  componi'iits.  I  he  defi'rred  de]x'ndency  relation  dr'scrilx'd  in  Sr'ction  2.3.2  inorh'ls 
■'hehavioral  dr’ix'ixlencies  which  dirr'ctly  snpj)orl  component-level  inaintenancr'  and 
rerpiirr'  the  introduction  of  concrete  tem])lat('.s. 

2.4.1  Fixed  Dependencies 

In  Sectioti  2.2  we  noted  that  a  titiit  (a  coinponr'nt  or  math  modiilr')  may  he  dt'fined 
dirr  r  tly  (ir  inrlirectly  in  terms  of  a  finitt'  ntimhr'r  rrf  otht'r  cr)ni])onr'nts.  Furthermore, 
out  definition  of  a  •r-oinponent"  reritiires  that  all  dirr'ct  rlr'jiendt'iicir's  hr'  part  of  a 
r-onijxment's  context.  Fsing  the  ctx  ftinction  (F.ijtiation  2.1)  we  now  dr'fine  tlir'  gr'iieral 
r  rnij)ling  rr'Iation  ovr-r  all  cotnpotx  iifs.  The  rr'latioti  usesiT'  x  C\  is  tlr'fint'd  rer  iirsivt'ly 
a-  follows: 


lises(c|.cj)  =  r,  -  ry.  V 

ry  G  CXt(r  i)  V  (2. .3) 

3c  G  CXt(r'i)  I  uses(r-.  ry) 

1  hr'  prr'rlicate  usps(r|.ry)  may  hr'  rr'arl  as  ‘'ratinponr'iit  ry  list's  coinitont'iit  (■■>'  .  In 
the  first  rlisinnct  of  iht'  rlefinit itrii.  ry  anrl  ry  rlr’iiote  tlx'  same  r'omiitxir'iit  (not  twrr 
rlifferent  compont'iits  wit  h  1  he  same  r-ontent ).  In  1  Ix' .sr'cond  case,  ry  rli'penrls  dirt'ctlv 
on  ry.  In  the  rt'rairsi vt'  case  (which  is  not  nutttially  exclnsivt'  with  I'ither  rtf  the  first 
two  casfs)  ry  rlepends  rlirectly  on  .soiiu'  r-rtmjtonent  that  dr'jtenrls  t'itlx'r  directly  or 
inrlirr'ct ly  t>n  (or  is)  ry. 

I  he  uses  rr'Iation  is  rr'fh'xive  anrl  transitive.  It  is  reflt'xivr'  to  inorlel  tlu'  jtossihilitv 
of  features  rlefined  within  a  comitriiient  heing  rli'finerl  in  terms  of  other  ft'atures  rh'finerl 
within  the  satne  component.  .A  coinponr'nt  may  iirtt  hr'  a  mr'inher  rtf  its  rtwn  ertntext 
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Figure  2.8:  Concrete  Instances  Forming  A  Component-Based  System 


since  ctx  is  used  to  express  a  component’s  external  dependencies.  However,  if  ctx 
were  a  reflexive  relation,  then  uses  simply  would  be  the  transitive  closure  of  ctx. 
Note  that  two  components  may  depend  mutually  upon  each  other  (e.g.,  uses(ci,C2) 
and  uses (c2.  Cl))  may  both  hold)  as  long  as  components  Ci  and  C2  are  well-formed 
according  to  the  rules  of  L. 

If  Cl  uses  C2,  then  component  ci  in  some  way  depends  upon  component  C2.  If  Ci 
and  C2  are  both  concrete  instances,  then  operations  implemented  in  Ci  might  invoke, 
either  directly  or  indirectly,  operations  implemented  in  C2.  If  C2  is  a  specification, 
then  Cl  may  depend  on  all  or  part  of  C2  to  explain  behavior  that  it  uses,  extends,  or 
implements  (if  ci  is  an-  implementation) .  To  fully  understand  and  justify  properties 
about  the  behavior  described  (implemented  or  specified)  by  component  c,  a  software 
engineer  may  need  to  understand  the  behavior  described  by  all  other  components 
(both  implementations  and  specifications)  used  by  c. 

Once  a  component-based  system  has  been  fully  integrated,  the  behavior  of  the 
system  depends  only  on  concrete  instances.  We  can  characterize  the  inter-component 
dependencies  in  a  fully  integrated  system  solely  in  terms  of  the  uses  relation  restricted 
to  concrete  instances.  Figure  2.8  shows  two  views  of  a  simple  component-based  system 
composed  of  five  concrete  instances:  Al,  Bl,  Cl,  Dl,  and  El,  all  members  of  (77.  On  the 
left  side  of  Figure  2.8,  the  arrows  between  components  represent  direct  dependencies. 
Thus  we  may  conclude  that  that  ctx(Al)  =  {Bl,  Cl},  ctx(Bl)  =  (Dl,  El},  and  ctx(Cl) 
=  {El}.  Component  Al  corresponds  to  a  “main  program”  and  components  Dl  and 
El  are  components  implemented  entirely  in  terms  of  built-in  features  of  L.  The  right 
side  of  Figure  2.8  shows  the  sub-graph  of  the  uses  relation  induced  by  just  these  five 
concrete  instances.  An  arrow  from  component  Ci  to  component  C2  indicates  that  the 
predicate  uses(ci,C2)  holds. 
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If  uses'r  i.  fj)  liolcls.  tin’ll  (•()iii])f)iK'iit  is  ••hard  wired"  to  coinpoiK'nt  e|,  Tln'ie  is 
a  fin  (I  de])eiidf'nev  of  f|  on  cj  that  cannot  lie  (■lianti;('d.'  Any  system  nsiny  ci  must  also 
use  r_>  a'^  a  result  of  this  d('])end('ney.  If  a  nuiintaiiH'r  wislu’s  to  re])lae<’  ('■>  with  another 
eoiniiatil.le  component,  then  r,  must  also  he  replaced  since  it  depends  specifically  on 
fj.  .Vs  a  rc'snit.  coiiipiiiinils  with  fixed  d('])end('nei('s  on  oiIk’I'  im])letn('ntations,  like 
Al.  Bl.  and  Cl  in  l  iyiire  2.S.  do  not  snp])ort  eomjionent-levi'l  maintc’iianee.  In  the 
f..ll  nwiim  \vf'  fuldrc'ss  this  prohlf'iii. 

2.4.2  Deferred  Dependencies 

As  w('  discussed  in  Sc'ction  2.1.3.  in  order  to  foster  snhstitntahility.  eom])onents 
must  he  designed  and  im|)lenK'nted  to  roiifoi'iii  to  Ix’haAioi'al  interfaei's  anrl  also  to 
nqinn  ns('  of  any  eomi)onents  that  conform  to  those  interfaces.  C’onsirh'r  asain  tin' 
component  la’lat  ionships  (h’pictc'd  in  f  ifj;nr(’  2.2.  For  now.  assume  that  tin'  eh’ment 
t\pe  of  list .  stack,  atid  cjueiu'  has  h(>('n  fix('d.  say  to  tyjx'  Integer.  (We  will  consich’r 
the  more  general  case  without  this  assumption  later  in  this  section.)  If  we  model  the 
(Integer)  list  impletix'titations  on  the  hottom  of  tlx'  figure  as  eom]X)tients  in  C'l  and 
the  (Integer)  list  intc’rfacf'  iti  the  center  as  a  siieeification  in  AI.  then  tlx’  "conforms 
to  relationship  shown  may  he  modeled  hy  tlx'  imps  rehition  (h'fined  in  E(itiatioti  2.2. 
1  he  issue  we  address  in  this  section  is  how  to  nuxh'l  the  "refinirt’s  an  implementation 
of"  r('lationshi])s  shown  on  the  top  of  Figure  2.2. 

It  would  Ix'  convenient  to  itse  elements  of  C'l  as  the  models  for  all  implementation 
{■(•mixxx'nts.  However,  itniilenx’iitations  with  de])end('nri(>s  ex])r(’.ssed  in  terms  of 
a  heha\'ioial  intc'iface  siiecification  art’  different  in  kitid  from  implementations  that 
have  fixed  deix’iidencies.  lo  ttnderstand  the  rlifference.  consider  the  five  compoiK’nts 
sliDwn  in  figure  2.9.  .Assittne  that  the  two  list  implementations  at  the  hottom  of 
the  figure.  ILl  ami  IL2.  are  implementations  in  C'l  with  no  external  de])endencies. 

I  hat  is.  they  oidy  use  o])erations  and  (v]x’s  ])rovided  directly  hy  L  (including,  in 
thi"  (’xample.  ty])e  Integer).  .Assniix’  that  the  Ix’havioral  interface  d(’])ieted  in  the 
(entei  of  the  figure.  IL.  is  a  sp(’cifieat ion  in  AI  ami  that  hoth  list  imph’im’utations 
conform  to  this  spc’cificat ion  as  indieat(’d  hy  tlx’  arrows  lalx’h’d  imps.  The  stack 
implementation  fh’pictc’d  in  tlx’  U])])ei'  left  eoriu’r  of  the  figure.  ISl.  diif'ctlv  us(’s  list 
implementation  ILl  as  shown.  \\('  may  imxh'l  ISl  as  a  component  in  C'l  with  a 
crirresj)onding  Ix'havior  J>(IS1)  defim’d  in  t('rms  of  5(IL1). 

1  he  eom])onent  lalx'h'd  ISTl  in  tlx’  u|)]X’r  right  eoi'm’r  of  Figure'  2.9  is  an  Integer 
stack  ini])leim'ntation  that  may  use  ain/  list  imph’im’Utation  that  eoid'orms  to  IL.  W'v 
say  that  ISTl  has  a  thfcrnd  (lijicnfliiic!/  on  an  im])l(’im’ntation  of  IL  or  that  it 
■■m'(‘(F  an  inpeh’im'titation  of  IL.  (We  defim’  the  needs  relation  helow.)  Assume 
that  the  content  of  ISTl  is  ich’iitical  to  that  of  ISl  exe(’i)t  that  when’  ISl  names  list 

'Since  tin-  set  of  nil  courreie  insttinces  Cl  is  fixed  in  oiir  model,  "nxilxing  a  clxmge  to  ci"  is 
etinivnleiiT  to  sliiftine  attention  to  tinotlxT  cotnitonetit  in  Cl  tliat  m;iy  or  may  not  depend  on  r>. 
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Figure  2.9:  Fixed  and  Deferred  Dependencies 


operations  specifically  provided  by  ILl,  ISTl  refers  to  list  operations  as  specified  in 
IL.  (We  will  examine  the  details  of  how  a  component  with  deferred  dependencies  may 
be  encoded  in  specific  programming  languages  in  Chapters  4  and  5.)  The  problem 
with  modeling  ISTl  as  a  concrete  instance  is  that  this  component  does  not  describe 
a  single  component  behavior  in  B.  ISTl  characterizes  a  set  with  as  many  different 
stack  behaviors  as  there  are  list  behaviors  in  <S(IL).  If  we  select  ILl  to  satisfy  ISTl’s 
need  for  an  implementation  of  IL,  then  we  expect  the  resulting  behavior  to  be  the 
same  as  that  described  by  ISl.  If  we  select  IL2  instead,  then  the  resulting  behavior 
may  be  different. 

We  model  implementation  components  with  deferred  dependencies  as  members  of 
the  set  CT  of  concrete  templates  introduced  in  Section  2.2.1.  A  component  with  a 
deferred  dependency  may  be  viewed  as  a  template  for  generating  concrete  instances. 
We  model  the  meaning  of  a  concrete  template  as  a  function  from  one  behavior  in  B 
to  another  behavior  in  B.  The  semantic  function  S  (restricted  to  the  domain  CT) 
maps  each  concrete  template  t  E  CT  to  a  function  in  the  set  of  all  functions  from  B 
to  B.  The  domain  of  the  function  S{t)  is  the  subset  of  B  defined  by  the  specification 
a  E  AI  used  to  express  the  deferred  dependency  of  t.  The  range  of  S{t)  is  the  subset 
of  B  that  includes  the  behaviors  corresponding  to  all  concrete  instances  that  may  be 
generated  by  instantiating  t  with  any  concrete  instance  that  implements  a. 

The  relation  needs  :  CT  x  AI  models  a  deferred  dependency  between  a  concrete 
template  and  an  abstract  instance.  The  relation  is  defined  as  follows: 
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neecls(/.  a)  =  (l()iiiaiii(5(/))  =  S{(i)  (2.0) 

1  li('  pn'dicat (■  ncccls(/.r;)  may  ho  roafl  as  ■■(■()nor('t('  t('m])lat('  /  noc'ds  an  iin])l('- 
iiiontation  (aiiy  implomontat  ion)  of  abstract  instance  n" .  For  any  r  6  Cl  for  whicli 
imps'e.  (i)  holds,  the  result  of  instantiating  /  with  r  is  a  eonen'te  instance  r'  for  which 
use.s'r'.r  )  holds,  d  liat  is.  the  eoneret(>  instancf'  generated  hy  tlie  instantiation  ns('s 
tho  eonerete  instane('  that  was  chosen  to  instantiat('  tlu'  concrete  template. 

l  iuiiri'  2.10  shows  how  the  eom])onents  and  relationships  in  Fi.yure  2.0  (exec'pt  for 
IL2i  are  moddrcl.  ISTl.  tlu'  stack  imphnnent ation  that  ms'ds  any  eonerete  instance 
that  implenu'nts  IL.  is  nuxh'led  as  a  eonerc'te  template*  in  Cl .  ISTl  s  (h'h'rre’d  de'pen- 
deney  on  an  implenu'iitation  of  IL  is  indicated  hy  the*  arrow  labeled  needs  from  ISTl 
in  r  7  to  IL  in  .  1/.  J  lie  semant ie  fnnet ion  i5  maps  ISTl  to  the*  ('h’liK'iit  .5( ISTl )  in  tlu* 
set  of  functions  from  H  to  B.  Since  ISTl  nee'ds  an  im])lementation  of  IL.  the*  domain 
of  the  fnnet  ion  .SI  ISTl )  is  <S(  IL)  which  is  d('])iet('d  by  t  In*  dashed  oval  within  D.  Since 
the  list  imiilementation  ILl  imjileiiK'nts  the  list  s|)('eifieation  IL.  ILl  may  he*  used  to 
fulfill  ISTl  s  re()uir('m('nl .  I  in,nr('  2.10  conveys  this  on  the*  h'ft  side*  with  the  needs 
and  imps  relationshi])s  ami  on  the  riyht  side*  by  showint;  the  belnnior  (5>(IL1)  in  the 
subset  ,5>(  IL)  of  B.  \\  Ih'Ii  the*  function  <5(IST1)  is  apjilie'd  to  the’  behavior  <5(IL1)  the* 
result  is  the  behavior  5(IS1)  as  dejiieted  by  the*  dashed  lim*  from  5(IL1)  to  cS(ISl). 
Tims  the*  behavior  imiilemented  by  the  eonerete  tem])l,at('  ISTl  instantiated  with  the 
eomreti*  instance*  ILl  is  tlx*  same*  as  the*  behavior  inpilementt'd  by  ISl  with  its  fixe'd 
fh*p(*iKh*nev  on  ILl. 

I  he  final  aspf'ci  of  the  mod(*l  is  tlx*  nx'anin.y  of  abstract  temphites.  We  nxxh'l  the 
nx*aniny  of  an  abstract  temiilate*  as  a  function  from  tlx*  set  B  of  b(*haviors  to  the  s(*t 
T'\B].  the  power  s(*t  of  behaxiors.  for  an  abstract  t(*mplate  u  E  AT  anrl  a  concrete* 
iiisTanee*  c  E  Cl.  tlie'ie*  is  an  abstiaet  instane’e*  a  E  Af  sue’h  that  S{ti){S(c))  =  <5(e;). 
dims  the*  meaning  e»f  an  abstrae-t  te*mplate  may  be*  vie'we*el  as  a  fuix’tiein  that.  whe*n 
appli(*el  to  the*  me*anin.u:  eif  an  im])le'mentat  ion.  pre)eluee*s  the*  meaning  of  a  speeifie-atiem. 
I  his  is  a  some*what  differe*nt  meielel  eif  abstiae  t  t(*mplate>s  than  that  ele'fined  by  ACTF. 
Xe‘\('rt lx*l(*ss.  this  \  ii'w  eif  abstrae-t  te*mplate's  is  suffie  ie'iit  for  emr  nee'els  as  ])i-(*se'nte'el 
in  Chapte'r  3. 

l  iyure*  2.11  shows  all  eif  the*  sjiae-e-s  de*fine'd  within  tlx*  mexh’l  ine-lueling  the  set 
eif  abstrae-t  te’iiiplate's  AI  ami  the*  si't  eif  matlx'inat ieal  tlx'eiry  nxieliile’s  M.  In  this 
fiuiire*.  the*  abstrae-t  te*mplate'  LT  is  a  s]ie*e-ifie-atiein  eif  a  list  just  like*  IL.  exe-(']it  that 
it  is  paramete*ri/e'ei  by  the  tyjie*  eif  ite*m  e-eintaine'el  in  tlx*  list.  That  is.  LT  spee-ifie's 
a  li't  te'injilate*  rathe*r  than  an  inte*ge*r  list.  The*  (-eimpenx'nts  I  ami  II  r('pre*se'nt  an 
inte'oer  tyjie*  s]ie*e-ifie-ation  ami  im]ile'mentatiein.  re*s]ie*e-tivelv.  (Altlxingh  tlx'se*  are  not 
ele*i)ie-t(*el  in  Fiyiire  2.11.  ISl  u.se.s  II.  ILl  uses  II.  ISTl  uses  II.  ami  IL  uses  II.)  In 
this  situatieiii.  tlx*  be*havior  siie'e-ifie*el  by  instantiating  LT  with  II  is  the*  same  as  that 

Ill  tlx'  .-\C  II  iiioeld.  ail  alistrae-t  te’iiijileite'  is  a  fuiu-tieiii  fidiii  an  (ihstnirt  itistniirr  to  anotlx*!' 
iii-T;nir(‘.  flLdwO*). 


imps 

imps(e-.  ei  )  =  5(e')  G  5(e/) 

exts 

exts(e/j.  e/, )  =  5(e/2)  C  5(e/| ) 

uses 

usesle'j.eo)  =  n  =  r-^V 

('■j  G  CXt(e’i)V 

3e'  G  cxtfe'i )  1  uses(e-.  e_.) 

needs 

neecls(/.e;)  ee  ele)main(5(/))  =  5(e/) 

l;il)I('  2.1:  Suminarv  of  Modeled  C'oini)oiient  Id'hitions 


.‘'peeified  hy  IL.  lids  instantiation  of  LT  is  d('])iet('d  in  Fignn'  2.11  as  the  fnnetion 
application  arrow  travelitiu,  fr(tni  5(11)  in  li  tlironyli  the  fnnctioti  5(LT)  to  5(IL)  in 
Vifh. 

I  iyiire  2.1]  also  shows  that  the  iiit e,u,('r  specification,  abstract  t('n)i)late  I.  ch'pends 
on  the  inatheniatieal  inte,”;(>r  theory  deseri]>tion  ITHRY.  Tlu-  itit(>rpr('tation  of  ITHRY. 
Xi  ITHRY).  is  shown  simply  as  a  i)oint  in  1  .  All  of  tlu'  eotn])onents  (stritigs  in  L)  shown 
in  the  fimire  rcdy  either  directly  or  iiiflireetly  on  ITHRY  (tlu'.sc'  uses  relation.shi])s  are 
not  shown  to  reduce  elntter).  'Jims,  each  eonipoiu'nt 's  nu-aiung.  shown  as  a  point  or 
function  la  set)  in  \'.  is  <'onst  rnctc'd.  in  i)art.  from  t  lie  .set  X(ITHRY). 


2.5  Chapter  Summary 

In  this  chaptf'r  W('  lia\'('  deviToped  a  si't  theon'tie  model  of  Ix'havioral  relation- 
slii])'  lictwef'ii  sofiwart'  eom])on('nts.  I  he  pmposc'  of  this  inochT  is  to  (h'serilx'  tlu' 
lx'ha\  ioial  I'clat  ionshijis  Ix't wixm  software  eomjxiiK'nts  ixv'di'd  to  stipport  eom])onent- 
leve!  maintenance.  Section  2.1  motivali's  the  need  for  eomjionent-level  maintenanci' 
and  relationshi]).s  that  express  behavioral  eonformanee  and  behavioral  r('(|nirements. 
Si'ction  2.2  descrilx's  onr  eompoix'nt  moflel.  which  inclnch's  abstract  and  concrete 
template>  (iiaranx'ti'ii/f'd  sjiecifieat ions  and  inpih'nK'ntations).  abstract  and  concn'tc' 
in-'tanci's  |non-parameteri/('d  s|)ecifications  and  imph'iiumtations).  and  mathematical 

t  hc(  )i  y  modules. 

1  he  model  defines  the  meaning  of  each  eonereli'  instance  as  an  eletnent  in  the  set 
5  of  -behaviors".  'I'lie  mt'aning  of  an  abstract  instance'  is  defiiu'd  as  a  set  of  behaviors, 
a  nx'inber  of  the  |)ower  sf't  of  5.  TB.  'the  meaning  of  a  eonen'te  instance'  is  eh'fiix'el  as 
a  fmie'tion  from  B  to  B.  'J  lx'  nx'atiing  eif  an  abstrae't  te'tnjilate'  is  eh'fine'el  as  a  fnne'tiem 
from  5  to  VB. 

In  S(‘e  tion  2.;b  we'  eh'fine'el  imps,  a  e-emformane'c  relatieinship  be'twe'en  eonerete' 
atiel  abstrae  t  instane-e's,  anel  exts.  a  e'emformane'e  re'lat iemshij)  betwe'cn  twee  abstrae  t 
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n  .  Tfc/  T»Vk 


Figure  2.11;  The  Big  Picture 


iiist aiiccs.  In  Section  2.1  wr  ch’Iiiu'd  tin’  fixetl  (l('|)(’n(l('ncy  ndtition  uses  and  tin'  d('- 
ferred  dei)('iKl('ncy  relation  needs.  Tahle  2.1  lists  tlies('  ndations  aiif!  their  dedinitions. 


CHAPTER  3 


A  USEFUL  SET  OF  SOFTWARE  COMPONENT 

RELATIONSHIPS 


In  this  chapter  we  define  a  useful  set  of  software  component  relationships  based 
on  the  model  of  components  and  relations  developed  in  Chapter  2.  We  do  not  claim 
that  these  are  the  only  useful  relationships  between  components  nor  do  we  claim  that 
they  are  ideally  suited  to  all  approaches  to  software  development.  However,  as  we  will 
explain,  the  relationships  presented  in  this  chapter  are  well-suited  for  building  and 
maintaining  component-based  software  systems.  In  this  chapter  we  also  introduce  the 
graphical  notation  of  component  coupling  diagrams  used  to  depict  each  relationship 
described. 

This  chapter  presents  a  sequence  of  simple  example  components  to  demonstrate 
the  relationships  described.  Section  3.1  introduces  a  specification  and  implementation 
notation  used  to  encode  example  components.  Section  3.2  describes  the  dependency 
relationship  uses,  corresponds  directly  to  the  uses  relation  described  in  Section  2.4.1. 
Section  3.3  describes  the  behavioral  relationship  implements  which  is  based  on  the 
imps  relation  described  in  Section  2.3.1.  Section  3.4  describes  the  deferred  depen¬ 
dency  relationship  needs  which  is  based  on  the  needs  relation  described  in  Sec¬ 
tion  2.4.2.  Section  3.5  describes  the  behavioral  relationship  extends  which  is  based 
on  the  exts  relation  described  in  Section  2.3.2.  In  Section  3.7  we  provide  a  summary 
of  the  relationships  defined  in  this  chapter. 

3.1  Component  Notation 

The  component  relationships  described  in  this  chapter  are  language-independent 
in  the  sense  that  they  are  not  tied  to  specific  language  mechanisms.  The  relationships 
reflect  design-level  information  that  may  be  encoded  in  various  ways  with  various 
implementation  and  specification  languages.  Nevertheless,  some  languages  provide 
much  better  support  than  others  for  encoding  these  relationships.  Chapter  4  discusses 
language  support  for  encoding  these  relationships. 
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In  tills  clinplcr  we  prcscnit  rxninplc's  of  compotH'iits  encoded  in  a  ewstoin  notation 
^\itll  specification  elenu'nts  similar  to  tlios('  of  tin'  Hf.SOIA  E  lan,t!|na,u,('  and  ini])le- 
nientaiion  elements  similaf  to  those  of  Ada.  The  notation  lias  Ix'C’ii  simplified  (with 
re.^jiect  to  IfESf  )IA'l'.  and  Ada)  ill  onlvr  to  sliortiMi  ('xan]])l('  codf’  aiicl  inininii/('  tlio 
nor‘(l  to  ruldri'ss  dc'tails  not  dir(*(‘tly  n'h'vant  to  tlu‘  issti(\s  discusstnl  in  this  chaptca*. 
Sol  no  of  tlif'  siin])lificat  ions  involve'  nanu'  space'  (‘onti'ol  (use'  of  nnqnalifie'el  ve'rsiis  (piali- 
fienl  ieh'iitifie'r  name's),  o])e'ration  paranu'te'i*  nie)fle' s[)e'e-ifie'at ie)m  fe'ature's  built  inte)  tlu' 
lanuuaye'.  ini])le'nie'nt at ion-le'\'e'l  e'ne*a])sulatie)n,  olqe'eU  init iaii/at ie)n  and  fina!i/atie)n, 
anel  mine)!'  syiit aea  ie*  de't ails  (sue’li  as  the'  use'  e)f  se'niie‘ole)ns) .  d  he'  (*e)ni])e)ne'nts  f'ne‘ode'el 
in  I'{bS()IA  lA/AelaO  )  sheiwn  anel  elise'usse'el  in  C'hapte'r  o  aelelre'ss  the'se'  and  othe^r  is- 
suc>  with  spe'cific  solutie)ns  base'el  e)n  the'  ca])al)ilit ie's  aiifl  limit atie)ns  e)f  RESOIA'E 
anel  Aela. 

A^  in  C  hapte'T  2.  we'  use'  the'  te'rni  “e*e)mpe)n('nt  te)  re'fe'r  te)  a  se)ftware'  module'  that 
d<'^cril)e'>  ('ithe'r  an  im])le'nif'nt at ieui  e)f  l)e'havie)r  e)r  a  sp('e-ifie‘atie)n  of  l)f'havie)r.  Eur- 
the'Mnorf'  the'  eie'.se-l'ipt ieai  e)f  be'havie)]*  may  he'  paratneHe'rize'd  (a  te'mi)lat('  compe)ncnt) 
e>r  ne»t  (an  instanev  eaimpeine'nt ).  \\v  e’e)ntinue'  te)  use'  the'  te'rms  ‘•e-e)neT(ne'  instane*o*\ 
“cinicre'te' tf'm])late'  .  “abstraei  inst aiie-e'*\  anel  “abstrae-t  te'inplate'*'  te)  I'e'fe'r  te)  the' fe)ur 
kinrl>  of  e'om])one'nt s  whieE  re'sult  from  this  cate',u;e)ri/atie)n.  In  the'  e'xam])le's.  wo  will 
pre'fix  caeE  e'ompe)ne'nt  name'  with  the'  strin,!:;  -ClA,  e)r  “ATA  to  inelicatc 

its  e‘la-;sifie-nTion  as  one'  of  the'se'  four  kinels  e)f  e‘e)mpe)ne'nts.  Note'  that  this  is  a  namin,”; 
e*on\-e'nt ion  onl\-  ami  not  part  e)f  the'  ne)tatie)n  syntax. 

In  the'  notation  use'el  in  this  eiiapte'r,  be)th  s])e'e*ifie‘ation  e‘e)m])e)ne'nts  (abstrae-t  in- 
stam-f's  anel  abstrae*t  te’mi)late's)  ami  imple'me'iitat  ie)n  e‘e)ni])e)m'nts  (ce)ncre'te'  instane*e's 
anel  coiie’re'te'  te'inplate's)  are'  e'lie’oeh'el  with  the'  same'  basie*  fe)rniat.  EaeE  compe)- 
iH'nf  ha^:  a  he'arh'r,  nn  e)ptie)nal  context  se'e*tie)m  an  e)])tie)nal  auxiliary  se'e‘tie)m 
an  interface  se'e-tion.  and  a  terminal  end  eh'limite'r.  The’  lie'ade'r  be'gins  with  cithe'r 
specification  e)r  implementation  follow'e'el  by  the'  e*e)m])e)n('nt  name'  whieii  o])tie)n- 
allv  niav  be  feillowed  by  extends  elaiise's  in  spe'e*ifie*at ie)ns  and  implements  clause's 
in  imple'me'iitations.  d  he’  context  se'e-tion  lists  all  dire'e-t  fixe'el  de'pe'iiele'ncif's  ene-e)de'el 
with  uses  e'laiise's  followe’d  by  all  eh'fe'rre'el  ele'pe’mle'iie’ie's  ('ne'e)ele'el  with  needs  clauses, 
d  he*  eh'fe'rre'el  de'peneh'ne-ies  constitute'  the'  ce)m])e)nent  ])arame'ter  se'e-tion.  If  a  e-oin- 
peim'iiT  has  no  e'xte'rnal  ele'i)e'nde'ne-ie's  it  is  ce)nstrue-te‘el  soh'ly  in  terms  e)f  eh'inents 
built  inte)  the'  language*  the'U  its  emj)ty  e*onte'xt  se'e’tie)n  mav  be'  e)mitte'el. 

I  he'  auxiliary  se'e-tion  in  a  spe'cifie-atie)n  (-e)m])e)nent  may  ine-lueh'  ele'finitie)ns  that 
de'.scribe'  the'  be'havior  s])e'e-ifie’fl  in  the'  interface  se’e-tie)n.  In  adelitie)n  te)  si)e'cification- 
only  (h'finitions.  the*  auxiliary  se'e-tie)n  e)f  an  im])le'nientation  ce)niponent  also  may 
im  Imh’  Incal  eh'finit ions  e)f  ])ro,yram  type's,  e)perat  ie)ns.  ami  variable's  use'd  te)  eh'seribe' 
the*  be'ha\  ie)i  imph'ine'nt e'd  in  the*  interface  se'e-tie)n.  d  hat  is.  an\’  ])re)^u,ram  type's, 
ope’iations.  ami  variable's  eh'fine'el  in  the'  auxiliary  sectie)n  may  be'  refe'renced  onh' 
within  the'  re’maimh’r  e)f  that  see-tie)n  anel  in  the'  fe)lle)wing  interface  se'ctiem.  The 
auxiliary  se’e-tie)n  may  be  omit t eel  if  it  is  empty.  The'  interface  section  pre)vieles 
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specification  AI_Flipflop 
interface 

type  Flipflop  is  modeled  by  BOOLEAN 
exemplar  ff 
initially  ff  =  FALSE 

procedure  Toggle  (f  :  Flipflop) 

ensures  f  =  NOT  #f 

function  Test  (f  :  Flipflop)  :  Boolean 
ensures  Test  =  f 

end  AI_F lip flop 


Figure  3.1:  Abstract  Instance  AI_Flipflop 


a  specification  or  implementation  of  program  behavior  in  terms  of  program  types 
and  operations.  Program  type,  operation,  and  variable  definitions  in  the  interface 
section  may  be  made  available  for  use  by  other  components. 

Figure  3.1  shows  a  very  simple  abstract  instance  named  AI_Flipflop.  This  ab¬ 
stract  component  provides  a  model-based  specification  [Win90]  for  a  two-state  device, 
a  flip-flop,  for  which  the  current  state  may  be  toggled  and  tested  (queried).  The 
context  and  auxiliary  sections  are  not  shown  since  this  component  only  uses  built- 
in  types  and  operations.  The  interface  section  includes  definitions  of  the  abstract 
data  type  Flipflop  and  two  associated  operations  Toggle  and  Test. 

The  examples  in  this  chapter  assume  that  all  components  have  visibility  over  the 
components  CI_Boolean_l  and  CI_Integer_l  that  define  the  scalar  program  types 
Boolean  and  Integer.  These  types  and  their  associated  operations  (e.g.,  or  for 
Boolean  and  +  for  Integer)  may  be  used  without  any  reference  in  the  context  section 
to  the  components  in  which  they  are  defined.  Thus  Boolean  and  Integer  may 
be  considered  as  built-in  program  types  of  the  language.  As  in  most  programming 
languages,  program  types  are  used  to  ensure  that  program  variables  are  used  in  legal 
contexts. 

The  program  types  Boolean  and  Integer  are  modeled  by  the  math  types  BOOLEAN 
and  INTEGER,  respectively.  The  math  types  BOOLEAN  and  INTEGER  are  specified  in  the 
math  theory  modules  MI_Boolean_Theory  and  MI_Integer_Theory.  These  two  math 
theory  modules  are  also  built-in  theories  of  the  language  in  the  sense  that  the  math 
types  and  math  operations  that  they  define  (e.g,  OR  for  BOOLEAN  and  +  for  INTEGER) 
may  be  referenced  without  mentioning  their  defining  math  theory  modules  in  the 
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CDiitc'xt  section.  M;itli  tlieory  inofliiles  provide  fornittl  six'cificatioii  of  iiiatlieintitical 
tlieoiio  tliai  m;iy  lx*  list'd  to  nitit Ix'iiitit ictilly  model  ])roeiam  behavior.  Tlie\'  seix'e 
till'  same  role  as  imilli  motiiiles  in  HllSOIA'E  [WOZOj]  and  as  fniits  in  tlx'  Larcli 
Sliaretl  Ltmuiniiie  [CiflWSoj.  Xott*  tlnit  we  do  not  considt'r  math  modules  to  be 
soliVwirt'  ■■com]x)nents  since  tlx'y  do  tiot  de.scribe  iiroertitn  Ix'havior  and  tlx'ir  nst' 
in  no  way  eflects  tht'  ojierational  behavior  of  component-bast'd  systems.  To  help 
di'-tinmiish  Ix'tween  program  and  imith  types  and  operations,  we  nst'  all  np])er  cast' 
itlentifiers  for  math  typt's  atxl  opt'iations  anti  mixed  cast'  itlt'iitifiers  fttr  program  typt's 
anti  t)per;it ions.  C  timmtxi  tijit'i  tittir  symbtils  such  as  "+  and  "=  art' oxct'pt ions  and 
m;l^•  Ix'  tlistingiiisht'tl  by  ctxitext. 

In  the  interface  st'ctioti  of  AI.Flipflop  (figure  3.1)  pfogram  typt'  Flipflop  is 
dechirt'fl  by  dt'fining  its  mathematical  mtitlel  to  Ix'  the  math  tyjte  BOOLEAN.  Tims,  tht' 
tili.'f t  st;itt'  s]);ici'  used  to  mtxlt'l  ;i  fli])-flt)p  is  tht'  set  {FALSE.  TRUE}.  Tht'  exemplar 
chm-'t'  sttites  that  tht'  ith'iit ifii'r  ff  will  rt'itrt'st'iil  a  jtrottitypical  ttbjt'ct  fttr  specif\'ing 
propi'rtit's  tif  idl  ttbjt'cts  (valnt's  of  vjiriablt's)  of  type  Flipflop.  Tht'  initially  clanst' 
st;ite>  that  the  inititd  abstrtict  statt'  ttf  a  Flipflop  object  is  FALSE. 

I  111'  o])i'r;ition  Toggle  is  s]x'cifif'fl  using  a  rt'lational  procedure  signature  that 
ttiki".  a  Flipflop  object  as  its  singlt'  argnmi'iit.  Ext'cntion  of  a  procf'tlurt'  nniy  chatige 
the  ab>ti';ict  values  of  till  of  thi'  opi'ration's  arguments.  Tht'  pit'-contlition  of  Toggle. 
i'X]>ri'ssr'd  by  a  requires  chmsi'.  is  not  shown  sinct'  it  |)hic('s  no  rt'st rict  ions  on  thi' 
st;ite>  from  which  Toggle  may  bt'  mt'atiingfnlly  invokt'd  (a  flip-flo])  may  be  toggli'd 
from  t'itht'r  state).  I  he  post-coixlition  of  Toggle,  ex'itrt'ssi'il  by  tht'  ensures  chinse. 
spt'cifii's  tlnit  after  ext'cntion  of  Toggle  tht'  abstract  stati'  corre.s])onditig  to  the  con- 
crete  statf'  of  tht'  argument  is  thi'  ni'gation  of  tht'  abstract  stati'  ])rior  to  ext'cntion. 
In  requires  and  ensures  chm.st's.  fornnd  paranu'ti'r  idi'iitifii'is  (f  in  this  exampli') 
flenote  obji'cts  of  tht'  nnith  typi'  nst'tl  to  mtxlt'l  tht'  jiaramt'ti'f  s  program  tvpi'.  In 
ati  ensures  clause,  an  argiuiK'tit  prt'fixi'd  by  di'iiott's  tht'  valiii'  of  the  argnment 
jirinr  to  I'xi'cntioii  of  tht' opi'ration  Ix'ing  s])t'cilii'd.  Thus  Toggle  chatigt's  tht'  flip-Hop 
fiiuii  one  stati'  to  tht'  othi'r  stati'. 

1  ht'  o])i'iation  Test  is  sjx'cifit'd  nsing  a  function  signatiiri'  that  takes  a  Flipflop 
object  as  its  singlt'  argmnt'iit  anti  returns  a  \aluf'  of  the  roiirri'tc  program  tvjie 
Boolean  (ih'fiix'd  by  thi'  coticrt'ti'  instanct'  CI_Boolean_l).  Execution  of  a  fmx  tion 
may  not  change  tht'  (ihstinct  wdni'  of  any  of  tht'  opi'ration's  argmnents.  Tht'  assi'rtion 
that  function  argumt'iit  valni's  tlo  not  changt'  is  an  iniiilicil  cotijunct  of  a  function's 
ensures  clause.  Likt'  Toggle.  Test  has  ixi  pri'-condit ioii.  Tht'  ensures  clausi'  of 
Test  specifii's  that  thi'  valui'  ri'turned  by  Test  (dt'iioted  by  Test)  corresjxinils  to  tlu' 
ab'-iract  wiliie  of  Test  s  argumt'iit.  J  hiis  Test  may  bi'  list'd  to  ciuerv  thi'  statt'  of  tht' 
fli])-fi(pp.  As  a  bi'havioral  intt'rfact'  sjit'cification.  AI.Flipflop  retiuires  all  ctxiforming 
imph'int'nt  at  ions  to  ])ro\'itli'  (at  li'ast)  a  ri'pri'st'ntatitui  lor  tyjit'  Flipflop  (initiali/etl 
ttia  valiif' reprt'st'iit  ing  FALSE),  an  implt'mentation  for  Toggle,  anti  an  implemetitation 
for  Test. 
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implementation  CI_Flipf lop_2 
interface 

type  Flipflop  is  represented  by 

state  :  Integer  range  0  ..  255  :=  0 

end  representation 

procedure  Toggle  (f  :  Flipflop)  is 

begin 

f, state  :=  (f. state  +  1)  mod  256 
end  Toggle 

function  Test  (f  :  Flipflop)  :  Boolean  is 

begin 

return  ((f. state  mod  2)  =1) 
end  Test 

end  CI_Flipf lop_2 


Figure  3.2:  Concrete  Instance  CI_Flipf  lop_2 


Figure  3.2  shows  a  simple  concrete  component  named  CIJFlipf lop_2.  This  com¬ 
ponent  provides  one  of  infinitely  many  possible  implementations  of  the  flip-flop  ADT 
specified  by  AI_Flipf  lop.  By  convention  we  will  suffix  implementation  component 
names  with  an  underscore  followed  by  a  number  used  to  distinguish  between  different 
implementations  of  the  same  specification.  For  example,  the  name  “CI_Flipf  lop_2” 
may  be  interpreted  as  the  second  concrete  instance  implementing  AI_Flipf  lop.  (As¬ 
sume  that  Cl_Flipf  lop_l,  not  shown,  is  the  obvious  implementation  using  a  Boolean 
for  the  representation  of  Flipflop.)  The  structure  of  Cl_Flipf lop_2  is  very  similar 
to  that  of  Al_Flipflop  shown  in  Figure  3.1.  As  with  Al_Flipflop,  the  context  and 
auxiliary  sections  are  empty  and  not  shown  since  only  built-in  types  and  opera¬ 
tions  are  used  within  the  component.  The  interface  section  includes  a  definition 
of  the  concrete  program  type  Flipflop  and  implementations  of  the  two  associated 
operations  Toggle  and  Test. 

The  data  representation  of  type  Flipflop  in  Cl_Flipf lop_2  consists  of  a  single 
representation  component,  labeled  state.  The  state  component  is  an  object  of  the 
concrete  type  Integer  (as  defined  in  Cl_lnteger_l)  restricted  to  the  interval  [0, 
255]  and  having  an  initial  value  of  0.  The  operation  Toggle  increments  the  value  of 
its  argument’s  state  component  by  one  each  time  it  is  called  unless  the  value  is  255 
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in  wliifli  cnsf'  it  is  icsf't  to  0.  I  li('  (assi,i2,iiiii('nt )”.  +  (atldit ion),  and  mod  (inoduliis) 
oi)craiions  arc  provided  In-  Cl .Integer.l,  Tlic  operation  Test  returns  the  Boolean 
value  True  if  the  \  alue  of  it  s  ai'gunu'nt  s  state  eoi  upon  cut  is  odd.  ot  h('r\vis('  if  r('turns 
False. 

3.2  The  uses  Relationship 

I  lie  vises  r('lat  ionsliij)  deserilx's  the  fixi'd  .syntaetie  d('])('nd('ney  of  one  coinponent 
on  anotlu'r.  The  uses  ri'lationship  may  he  chdiiu'd  informally  as  follows: 

C  onijionent  C  \  uses  component  C'>  if  and  only  if  the  meaning  of  C\  de- 
pends  either  directly  or  indirt'ctly  on  tlu'  meaning  of  Th. 

I  he  vises  relationship  is  modeled  hy  tlu'  vises  relation  (hdiiu'd  in  Fniuation  2.~)  in 
C’ha])t('r  2.  If  comiKUU'nt  C\  uses  com])onent  Th  tUrvctlij.  then  Th  is  in  the  context 
of  r  1  and  entitii's  defined  in  C'>  may  Ix'  usc'd  in  tlie  definition  of  C'|.  If  comiionent 
f'l  uses  Component  fh  iiidincH//.  tlnui  C'>  is  not  in  tlu'  conti'xt  of  hut  is  in  the 
context  of  some  component  that  (\  uses.  In  both  cases,  t  he  Ixdiavior  either  specified 
ot  iniplenient('d  hy  C  |  depv’iuls  on  (is  (hdined  in  tc'itns  of)  tlu'  Ixdiavior  sjx'cifii'd  or 
implemented  hy  Td. 

I  he  vises  ndationship  is  vv'i  v  important  from  a  maintcuiancc'  p{'rs])('ctiv('.  If  eom- 
poiK'iit  C  1  uses  comjxinent  tlxui  any  modification  to  C'l  may  alter  tlx’  Ixdiavior 
deM-rihetl  hy  C\.  .Also,  in  order  to  fullv  uixh'rstaiid  a  component,  it  may  he  neci'ssary 
to  understand  aspi'cts  of  all  otlxu'  eomjxux'nts  that  it  vises.  Tlx'  uses  relationship  is 
often  viewed  as  a  •client /sup])lier"  relationshi|)  [.\Iey8S.  p.  73]  [BooOl.  ]>.  lOlj.  If  f'l 
vises  C  ,  then  (  i  is  a  rlifiit  of  C'j  which  is  a  supplier  to  C\.  Tlie  vises  ndationship 
give>  (  ,  nsihililn  to  elements  (hdined  in  Ch  and  (di'inents  (hdiix'd  in  components  that 
C 2  vises.  Depending  on  the  language  nu'chanisms  used.  C'l  may  or  may  not  have 
\i''ihility  to  all  featur('s  chdiiuxl  hy  C'j  and  tlx'  compoixuits  it  uses, 

d  hf'  most  familiar  form  of  vises  (h’scrilx's  coupling  hetwt'en  two  concrete  instances. 

I  his  rtdationship  should  he  familiar  to  anyoix'  who  has  d(’\-(dojx'd  software  using  a 
programming  language  that  supports  separately  eonipih'd  modiih’s.  1  Ix'si'  laiiguagv's 
have  import  or  inclusion  nu'chanisms  that  (uicixle  a  din'ct  uses  relationship  hetwi'cn 
two  iiKxluhc.  Examples  include  tlu'  with  context  clause'  in  .Ada.  tlx'  import  statement 
in  M(xlula-2.  and  the  #inclu(ae  preimx-i'ssor  directive  in  C'++.  In  the  notation 
luesented  in  this  ehapt('r.  a  direct  uses  n'lationship  is  encodc'd  with  a  uses  clause'" 
in  ih('  context  si'ction.  lor  exaiiiph'.  a  concrete'  instance'  huilt  specificallv  using 
CI_Flipflop_2  would  ine  huh'  in  its  context  se'ction  the'  clause  "uses  CI.Flipf  lop_2" . 

Hi  \v(  (■oii'idcr  ;=  ns  ;ni  operation  ele'fineel  on  tvpe  Integer,  !X)t  as  a  lerograin  statement  as 
in  .\<la. 

.Xiife  that  in  .-Vela,  tlx-  use  clause'  serve’s  the'  eliire'rcnt  jxnpeese’  eif  tillenviiig  iele'iitifie'rs  alreaelv  in 
seeipe  tei  hi'  re'fe-renecel  witlieiiit  Using  tlie’ir  fully  einalilie’el  natiu's. 


ALFlipflop  J 


I 


uses 


Cl  Boolean  1 


Figure  3.3:  The  uses  Relationship 


The  uses  relationship  also  may  describe  a  fixed  dependency  of  one  specification 
on  another  specification,  of  an  implementation  on  a  specification,  or  of  a  specifica¬ 
tion  on  an  implementation.  Figure  3.3  shows  a  component  coupling  diagram  (CCD) 
that  graphically  depicts  the  (implicit)  uses  relationship  between  AI_Flipflop  and 
CI-Boolean.l.  In  CCD’s,  abstract  components  (both  instances  and  templates)  are 
depicted  as  clear  boxes  with  rounded  corners.  Concrete  components  (instances  and 
templates)  are  depicted  as  shaded  rectangular  boxes.  The  component  name  is  shown 
within  each  box.  The  thick  solid  arrow  from  AI_Flipf  lop  to  CI_Booleaii_l  represents 
the  uses  relationship  between  the  two  components.  We  use  thick  arrows  to  depict 
dependency  (coupling)  relationships.  Note  that  typically  we  will  not  show  implicit 
dependencies  on  built-in  components  in  CCD’s  as  shown  in  this  example. 


3.3  The  implements  Relationship 

The  implements  relationship  is  a  behavioral  relationship  between  a  concrete  com¬ 
ponent  and  an  abstract  component.  The  implements  relationship  may  be  defined 
informally  as  follows: 

Concrete  component  C  implements  abstract  component  A  if  and  only  if 
C  provides  an  implementation  of  all  behavior  specified  by  A. 

The  implements  relationship  is  a  conformance  relationship  between  C  and  A 
modeled  by  the  imps  relation  defined  in  Equation  2.2.  However,  imps  describes 
a  relationship  between  instance  components  only.  We  extend  the  definition  of  im¬ 
plements  to  include  implementations  that  are  templates.  In  this  extended  view, 
implements  is  an  overloaded  term  for  three  distinct  relationships; 

•  If  C  is  a  concrete  instance  and  A  is  an  abstract  instance,  then  the  claim  that 
C  implements  A  is  an  assertion  that  imps(C','H.)  holds. 
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ALFlipflop  ^ 

i 

implements 

CI_Flipflop_2 

Fi,t;un‘  3.1:  ']'li('  implements  Hehilionsliii) 


•  If  C  is  fi  coiK  r('t('  tcniplalc  and  .1  is  an  abstract  instance',  then  the  claim  that  C 
implements  .-1  is  an  a.ssertion  that  for  (iin/  instantiation  C"  of  C.  imps(r''..4) 

holds. 

•  ifr  is  a  concrete'  te'iiiplate'  and  .1  is  an  ahstrae  t  te'ni])late.  tlu’n  the'  claim  that 
C  implements  .1  is  an  asse'rtieni  that  leer  (iiii/  instant iatieen  C  eef  C  tlie'ie'  exists 
sotiif  instant  iat ie)n  .1'  eef  .4.  sne-h  (hat  iinpsfT".  .4')  heelels. 

We  will  elise  nss  examieh's  eef  e'ae-h  eef  tlu'se  tlirt'e'  e'ase's  in  this  e-ha]iter.  In  this 
se'etion  Wf'  elisenss  the'  iirst  eaise',  the'  implements  re'latieenshii)  he'tween  a  cetne'ie'te 
iii'^tanee'  anel  an  abstract  instanee'.  In  Se'e  tieen  3.1  we  jne'st'iit  example’s  of  the'  eefher 
two  e'ase's. 

A"  an  example'  e)f  the  implements  re'lat ieenship,  ceensieh'r  the  abstract  instance 
AI_Flipflop  shown  in  l  ignrc'  3.1  anel  the'  e'eeiie  re'te'  instance'  CI_Flipf lop_2  sheewn 
in  l  iunre'  3.2.  We  rlditn  that  CI_Flipf lop_2  implements  AI_Flipflop.  That  is. 
anywhe're  that  tlie're  is  a  re'(|uirement  feer  the  behaA'ie)r  spe'e'ifie'd  by  AI_Flipflop.  the 
im])leme'ntatie)n  CI_Flipf lop_2  may  be'  used  tee  satisfy  that  recinirement .  Tliis  rela¬ 
tionship  is  cra])hie'ally  fh'pie'teel  in  the  C'C'D  in  Figure  3.1.  The  thin  .se)liel  arreew  freem 
CITlipflop_2  tei  AI_Flipflop  re])res('nts  the  implements  relatiemship  betwe'cn  the 
t Wo  e'oinjeeine'iit s.  We'  use  thin  ai'ieews  tee  eh'jtie't  be'havieeral  re'httionslii])s  which  are' not 
elepe'iide'iicy  (e'oni>ling)  re'lat ieeiiships. 

Asiele  from  its  sngge'stive'  mmu'  anel  eebvieais  strne-tnral  similarity,  the  e'eentent  of 
CI_Flipf lop.2  fis  sheewn  in  l  ignre'  3.2  ee)ntains  ne)  stateme'iit  eef  its  pnrpeerte'd  rela¬ 
tionship  to  AI.Flipflop.  If  we'  assume'  that  CI_Flipf lop_2  was  spee'ifieally  de'signe'd 
to  imiele'inent  AI-Flipflop.  then  it  see'tiis  natural  that  this  infeermatietn  sheetilel  be' 
re'e-eiifleel  in  the  seeiiree  e  exh'  eef  CI_Flipf lop-2  tee  he'l])  explain  the  inteneh'd  behavior 
eif  the'  e-omieoiie'iit  tee  preis])e'e't ive  maintainers.  Flirt herme)re'.  infeirmat iein  exiilaining 
li<>>r  CI_Flipf lop_2  may  be'  ^•iewe'ei  as  imple'inent ing  AI.Flipflop  weaild  alsei  be'  nse- 
fnl  to  anyone  atte'Dijiting  tei  justify  the'  e  laim  that  the  implements  relationship  re'ally 
floe's  liohl  be'twe'e'ii  tlie'se  two  e'eimpeiiie'nts. 


implementation  CI_Flipf lop_3 
implements  AI_Flipflop 

interface 

type  Flipflop  is  represented  by 

state  :  Integer  range  0  . .  255  :=  0 
end  representation 
exemplar  ff_rep 

correspondence  ff  =  ( (ff_rep. state  MOD  2)  =  1) 

procedure  Toggle  (f  :  Flipflop)  is 

begin 

f. state  :=  (f. state  +  1)  mod  256 
end  Toggle 

function  Test  (f  :  Flipflop)  :  Boolean  is 

begin 

return  ((f. state  mod  2)  =1) 
end  Test 

end  CI_Flipf lop_3 


Figure  3.5;  Concrete  Instance  CI_Flipf  lop_3 


Consider  the  concrete  instance  CI_Flipf  lop_3  shown  in  Figure  3.5.  The  only 
differences  between  CI_Flipflop_2  and  CI_Flipf lop_3  are  the  implements  clause 
in  the  header  and  the  exemplar  and  correspondence  clauses  in  interface  section 
of  CI_Flipflop_3.  None  of  these  three  additions  affects  the  operational  behavior 
described  by  CI_Flipf lop_3.  Thus  CI_Flipf lop_3  describes  an  implementation  of 
behavior  identical  to  behavior  implemented  by  CI_Flipf  lop_2. 

The  implements  clause  in  the  header  of  CI_Flipflop_3  explicitly  records  an 
intended  implements  relationship  with  AI_Flipflop.  The  exemplar  clause  and 
correspondence  clause  in  CI-Flipf lop_3  explain  an  intended  correspondence  be¬ 
tween  the  representation  states,  modeled  by  INTEGER,  and  the  abstract  states,  modeled 
by  BOOLEAN.  The  identifier  MOD  names  a  math  operation  for  integer  modulus  (MOD  is 
defined  in  MI_Integer_Theory).  The  name  f_rep. state  denotes  the  abstract  value 
corresponding  to  the  representation- level  value  of  the  state  field  of  an  object  of  type 
Flipflop.  Since  the  state  field  is  an  object  of  program  type  Integer,  its  values 
correspond  to  abstract  values  of  math  type  INTEGER.  The  correspondence  defines  the 
relation  {<0,FALSE>,  <1,TRUE>,  ...,  <254,FALSE>,  <255,  TRUE>}  mapping  even 
representation  values  to  the  abstract  state  FALSE  and  odd  values  to  TRUE. 
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I  lie  ion;)]  iiifomint ion  ('iicodcd  in  CI_Flipf lop_3  s('r\('s  sovc'inl  iisrful  ])nr- 
I  lie  stat('ni(>iit  tliat  CI.Flipf lop,.3  implements  AI.Flipflop  ••officially" 
refolds  dcsitin  intent  of  t lie  ini|)l('ni('nt('r  of  CI_Flipf  lop_3  and  ttdls  a  |)ot('ntial  inain- 
taincr  (or  a  lihrary  hrowsiny  tool)  where  to  look  for  a  dc'srript ion  of  tlie  r('(|nirenients 
tld^  eoinponent  innst  satisfy.  TIk'  implements  elanse  also  inala's  ('xplicit  the  ohliya- 
tion  that  CI.Flipf lop_3  must  eonforin  structurally  and  .semantically  to  AI_Flipflop 
when  iiscfl  as  ati  imph'inentation  of  AI^Flipflop.  For  ('xanij)l('.  th('  implements 
clause  shown  in  I'iyiire  .3..")  mi.ylil  nxinirt'  a  compih’r  to  cht'ck  for  th('  structural  con¬ 
formance  of  CI^Flipflop_3  to  AI_Flipflop  when  CI.Flipf lop_3  is  comi)il('d.  Both 
CI-Flipf lop.2  ;uid  CI_Flipf lop.3  coid'orm  struetnrally  to  AI.Flipflop  since  tlu'v 
pro\ide  a  rejuesentation  for  tlu'  tyjx'  Flipflop  and  operations  with  names  and  pa¬ 
rameter  profiles  tliat  iiKitch  tlios(’  of  AI„Flipflop. 

Witliin  a  lihrary  of  ••ceitifi('d“  components,  ifu'  implements  clause  (perliaps  in 
ohject  code  form)  also  miyiit  l)e  int('rpr('ted  as  a  statement  tliat  th('  implements 
relat ionshij)  lias  been  justified  to  wliatf'vi'r  di'grt'e  re(iuired.  In  this  case,  onlv  con¬ 
crete  components  that  Inivi'  hemi  c('rtifi('d  to  conform  structurally  and  stmiatiticallv 
to  the  specifications  which  they  claim  to  implement  would  Ix'  enten'd  into  tlx'  lihrarv. 
Oflicially  recording  just ified  implements  ndationships  elsi'wherc'.  liow('v('r.  jirovides 
a  more  fie.xihle  Solution,  hoi'  exam])le.  if  justified  implements  (and  extends)  rida- 
tionships  are  recorded  in  a  com]x)U('nt  lihrary  database',  new  n'lationshijis  may  lee 
addcfl  and  ('xist iny  ones  ••re\'oked"  without  modifying  atiy  component  content.  Sucli 
a  flat  abase  of  relationships  would  Ix'  useful  for  comiefxient  library  biowsiny  as  wi'll  as 
for  use  by  com])onent  intf'yration  tools. 

I  he  claim  tliat  a  concrete  com])on('nt  implements  an  abstract  component  is  an 
assf'i'tion  that  tlx'  concretf'  comixxx'nt  is  a  correrf  imiilementatifxi  with  n'spect  to 
tlx'  s]x‘cificat ion  |)rovided  liy  the  fibstract  component,  d'lx'  correspondence  clause 
imx  ifles  information  ix'cf'.ssary  for  formally  verifyiny  the  correct ix'ss  of  an  .A.DT  ami 
thus  fur  just  ifyiny  that  the  implements  relationship  holds  betwf'en  a  component  that 
ini])lcments  a  tyjx'  and  a  component  that  s|)ecifi('.s  tlx'  ty])e.  The  relation  (‘Xju'essed 
by  the  correspondence  clause  is  also  called  an  ahsfraef ion  fnnrtinn[\XiSG.  p  70].  a 
n  frirrr  Jiinrtinti[.]inm.  p  IS'2].  and  more  yi'iierally  an  ahstrnrtinn  rr/f//mn[S\V()07:. 

In  short,  the  correspondence  clause  jirovides  a  way  to  comiiare  the  ('ffect  of 
e.xecntiny  f>jx'rations  on  tlx'  concif'te  representation  staff'  fh'.scribf'fl  b\'  an  im])lf*nx'n- 
tation  eoinpoix'nt.  with  the  efli'ct  fif  exf'cntiny  tlie  sanx'  t)])erations  on  tlx'  abstract 
state  fle>cribed  by  a  spf'cificat ion  compoix'nf.  In  oifh'r  for  an  ini])li'nif'ntation  to 
be  coiisiflen'd  corif'ct .  any  conerf'te  staff'  rf'.icliable  from  a  h'gal  sf'f|Uf'ncf'  fif  (zero 
or  moil')  opi'rations  must  corrf's]x)ixl  to  an  abstract  state  reachabh'  from  the  same 
sf'fiuenci'  of  operations.  Note  that  llx'  initially  claiisf'  (as  sliowii  in  Fiyiiri'  3.1) 
ensures  that  tlx'  concrf'tf'  state  of  an  obji'ct  corres])onds  to  its  spf'cifif'fl  abstract  state 
prior  to  execution  of  any  operations  that  aflect  the  state  of  that  objf'ct.  Tliis  serves 
a''  a  ba^is  for  an  iixliietifui  aryimif'iit  statiny  that  after  an  arbitrarily  long  sef|uencf' 
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of  operations,  the  concrete  state  of  an  object  will  still  correspond  to  an  appropriate 
abstract  state  as  specified.  The  details  of  formally  justifying  the  implements  rela¬ 
tionship  are  beyond  the  scope  of  this  dissertation  and  have  been  discussed  elsewhere 
in  terms  of  formal  verification  of  ADT’s  [Hoa72,  LG86,  Jon90,  EH094]. 

AI_Flipf  lop,  CI_Flipf  lop_2,  and  CI_Flipf  lop_3  are  so  simple  that  the  claimed 
implements  relationships  appear  easily  justified  in  both  cases.  But  useful  software 
components  tend  to  be  much  more  complex  than  these  simple  examples.  In  general, 
the  process  of  convincingly  justifying  that  a  concrete  component  implements  an 
abstract  component  may  require  a  great  deal  of  effort  and  even  creativity.  By  ex¬ 
plicitly  stating  the  correspondence  between  an  implementation’s  data  representation 
and  a  model  used  to  specify  desired  program  behavior,  the  component  implementer 
documents  a  critical  aspect  of  how  the  behavior  described  by  an  implementation  may 
be  viewed  as  corresponding  to  the  behavior  described  by  a  specification. 

A  component  implementer  may  use  the  implements  relationship  to  state  how 
an  implementation  component,  possibly  in  object  code  form,  should  be  viewed  by 
prospective  clients.  By  claiming  that  concrete  component  C  implements  abstract 
component  A,  the  implementer  is  claiming  that  A  serves  as  an  appropriate  simplified 
description  or  “cover  story”  for  behavior  implemented  by  C.  With  CI_Flipf  lop_3, 
the  abstract  state  space  modeled  by  BOOLEAN  is  different  and  simpler  (much  smaller) 
than  the  concrete  state  space  of  INTEGER  modulo  256.  In  this  case,  AI_Flipflop 
presents  a  simpler  conceptual  view  or  “mental  model”  of  flip-flop  behavior  than  that 
described  by  CI_Flipflop_3.  In  addition  to  supporting  substitutability,  a  primary 
goal  of  establishing  the  implements  relationship  is  to  identify  an  abstract  description 
of  an  implementation’s  behavior  that  is  easier  for  a  client  to  understand  than  the 
description  of  behavior  provided  by  the  implementation. 

The  benefits  of  including  the  implements,  exemplar,  and  correspondence  clauses 
in  a  concrete  component  should  be  clear.  Nevertheless,  there  are  reasons  why  it  might 
be  useful  to  maintain  this  information  elsewhere,  either  in  addition  to,  or  perhaps  even 
instead  of  maintaining  it  within  the  content  of  concrete  components.  We  discuss  this 
issue  in  Section  4.3.5.  For  now,  we  reiterate  that  the  implements  relationship  to 
AI_Flipf  lop  may  be  justified  for  both  CI_Flipf  lop_2  and  CI_Flipf  lop_3  and  that 
the  additional  information  provided  by  CI_Flipf  lop_3  serves  to  explain  how  this 
implements  relationship  may  be  justified. 

3.4  The  needs  Relationship 

The  needs  relationship  is  a  dependency  relationship  between  a  concrete  template 
and  an  abstract  instance.  It  expresses  a  deferred  dependency  between  an  instantiation 
of  the  concrete  template  and  an  implementation  of  the  abstract  instance.  The  needs 
relationship  may  be  defined  informally  as  follows: 
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Cinu'vrir  trnii)latr  f’  needs  ahstract  instaiin^  A  if  and  only  if  C'  uses  A 
aiifl.  fur  all  instantiations  of  C\  C  s  refc'nnioos  to  ])rosrain  ehniUMits  in  A 
arf'  rrplaof'd  hy  rf'ff'rrncns  to  tlu'  (‘orrrspondinn-  j)r()g‘rain  ('Irnu'iits  in  sonu' 
('oiHTf'tr  instance'  that  implements  A, 

T1j(^  rolatioiishii)  nanir  '“needs*'  is  short  for  “ikhhIs  an  iini)l(nnrntation  of".  TIh' 
needs  relation  ((hdiiif'd  in  hcination  2.0)  inochds  tln^  needs  relationslii])  Ix'twoon 
two  (‘oinponf'iits.  How('V(a*,  in  this  (‘ha])t(n’  wr  allow  a  connrc'tn  t('ni])latf'  to  havr 
morn  than  one'  ch'ff'ria'd  ch'pf'iuh'ncy.  I  hat  is.  a  sinp;h'  conerrto  trin])late  may  nrod 
imphaiumtations  of  more'  than  oik'  abstract  instance.  Fnrt h('rmore.  it  is  possibh^  that 
a  concia'tc  temi)lat(’  may  iummI  mon^  than  one’  im])l(Mnentation  of  the  san)r  abstract 
instancf'. 


3.4.1  Implementation-Level  needs 

B('for('  looking;  at  an  ('xam])l('  of  a  (hdcM’red  (h'penchmey  expr('ss('d  bv  th('  needs 
la’lat ionship.  wf‘  will  ('xamiiu'  a  (*los('ly  ix'latcxl  fixcnl  (l('p('n(h'iK*y  relationshi]).  To 
s('t  11])  both  exani])l('s,  W('  introduce  a  iif'w  abstract  instance'.  Fiii,‘ure  3.0  shows  the' 
abstrae-t  instance'  AI^Threeway  whieT  se'rve's  as  an  anste'i*e'  interfae*e  de'se’ribint;  the' 
be‘ha\*ior  e)f  a  *lhre'('-way  lie;ht  bulb  swite'h  with  eiiu'  “ofl  state'  anel  thre'e'  diffe'rent 
"on"  State's.  The'  auxiliary  .see'tiein  ineTieh's  the'  eh'eTiratiein  e)f  Z4.  a  math  snbtyiie 
e)f  IHTEGER  e-e)nst raine'el  te)  the'  interval  [0,3].  The'  interface  se'e*tie)n  e)f  AI.Threeway 
speeifics  the'  tyj)e'  Threeway  and  the'  e)])eratie)ns  Advance  anel  On.  The'  ty])e  Threeway 
i>  ineKie'lf'el  b\'  Z4.  'The'  de'si,i;ii  inte'iit  lie're'  is  that  the'  abstrael  state'  0  mode'ls  the 
sv'ite’h  s  e)fi  state'  anel  that  the'  state's  1.  2,  anel  3  meieh'l  the'  *'le)w",  '‘ine'dium*  .  anel 
"liieh  briyhtiH'ss  h've'ls  re'sjif'ct ive'ly.  Tlie'  Advance  eiperatiein  e*han,y('s  the  state'  e)f 
it^  areiinient  to  the'  next  hi,e;he'r  brightne'ss  h've'l  or  to  “eiff"  freim  "hip;h".  The  On 
e)])e'ration  re*tnrns  True  if  the'  switeT  is  in  one'  of  the'  thre'e'  "e)n"  state's  e*e)rre'S])e)nelini;‘ 
to  1.  2.  e)i'  3.  If  iK'ea'ssary.  a  eiie'iit  e‘e)nlel  e’yeT'  thi*e)nf;h  the'  switeii  state's  nsint;’  Advance 
anel  On  to  eh'te'rmine'  the'  bri,L!,ht ne'ss  \v\v\. 

fiyure'  .k  e  shows  the'  eaiiieax'ie'  instance'  CI_Threeway^l.  CI„Threeway_l  imple¬ 
ments  AI_Threeway  anel  uses  CI.Flipf lop_3  (she)wn  in  Fi,u;nre'  3,0)  te)  eh)  so.  The 
fixe'd  eh'pe'nele*ne-y  e)n  CI_Flipf lop_3  is  expre'sse'el  with  a  uses  eianse  in  the'  context 
se'ctioi).  Cl _Threeway_l  also  uses  AI.Threeway  in  etreh'i'  te)  e'X])re'ss  the'  e'e)rre'S])e>n- 
eleaiea'.  Since  CI_Threeway_l  uses  CI.Flipf lop„3.  it  has  elire'ef  ae-e-e'.ss  te)  the  rej)- 
re>f'nt  at  ion  e)f  ty])e  Flipflop  ele'fiiu'el  by  CI.Flipf  lop_3.  Freim  the'  ])e'rspe'e*tive  of 
CI._Threewa}wl.  the*  e*one‘re'te'  type'  Flipflop  is  me)ele*le'el  by  a  sinp;le'te)n  e)f  math  tvi)e 
IKTEGER  (the'  meieh'l  e)f  eaine-re'te'  ty])e'  Integer)  e*e)nstraine'el  te)  the  interval  [0,  255]. 
1  hn^  b\'  re'fe'i  rin,!;  te)  a  spe'eafie-  exine-ri't e'  (*e)m])e)ne'nt .  a  clie'iit  e‘e)m])e)ne'nt  siieii  as 
Cl _Threeva3^_l  e*e)mniits  te)  a  spe'e'ifie*  e‘e)ne‘re'te'  re'])re'se'ntat  iein. 

The'  auxiliary  se'e*tie)n  ineTiele'S  the'  eh'finit ie)n  e)f  the  math  e)pe'ratie)n  PARITY  use'el 
in  the'  correspondence  e'lanse'.  The'  interface  se'e-tie)n  de'fine's  the'  re'i)rf'se'ntatie)n  of 


specification  AI_Threeway 
auxiliary 

math  subtype  Z4  is  INTEGER 
exemplar  Z 

constraint  0  <=  Z  and  Z  <=  3 

interface 

type  Threeway  is  modeled  by  Z4 
exemplar  T 
initially  T  =  0 

procedure  Advance  (t  :  Threeway) 
ensures  t  =  (#t  +  1)  MOD  4 

function  On  (t  :  Threeway)  :  Boolean 
ensures  On  =  (t  >  0) 

end  AI_Threeway 


Figure  3.6:  Abstract  Instance  AI.Threeway 


type  Threeway  and  implementations  for  Advance  and  On.  The  representation  of  type 
Threeway  is  a  pair  of  objects,  labeled  ff  1  and  ff2,  both  of  type  Flipflop  as  defined 
in  CI_Flipf  lop_3.  These  two  objects  maintain  which  of  the  four  states  the  switch  is 
in  as  explained  by  the  correspondence.  The  two  flip-flops  are  simply  used  as  a  two-bit 
counter.  Since  CI_Flipf lop_3  represents  Flipflop  with  an  object  of  type  Integer 
constrained  to  the  interval  [0,  255],  CI_Threeway_l  represents  Threeway  as  a  pair 
of  objects  of  type  Integer.  Thus  the  representation-level  model  of  type  Threeway 
as  defined  by  CI_Threeway_l  is  a  pair  of  INTEGER  objects  with  values  constrained  to 
the  interval  [0 ,  255] . 

The  correspondence  clause  defines  a  relation  mapping  each  of  the  256^  represen¬ 
tation  states  to  one  of  the  four  abstract  states  of  Threeway  defined  in  AI.Threeway. 
For  example,  any  representation  in  which  both  flip-flop  objects  have  an  even  value, 
maps  to  the  abstract  state  0  which  models  the  switch  in  the  “off”  position. 

The  implementation  of  the  Advance  operation  is  defined  in  terms  of  Toggle  and 
Test.  The  implementation  of  On  is  defined  in  terms  of  just  Test.  These  imple¬ 
mentations  do  not  directly  access  the  representation-level  state  of  the  flip-flops  they 
manipulate.  Thus  in  this  case,  there  is  no  reason  why  CI-Threeway_l  needs  to  be 
designed  with  a  fixed  dependency  on  CI_Flipf  lop_3.  Nevertheless,  without  reference 
to  an  abstract  specification  of  CI_Flipf  lop_3  (at  the  point  in  CI-Threeway_l  where 
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implementation  CI_Tlircov;ay„l 
imp  1  ement  s  A I  _Th  r  c  c v/a  y 

context 

uses  CI_F1 ipf lop_3 

auxiliary 

math  operation  PARITY  (I  :  INTEGER)  :  INTEGER 

definition  I  KOD  2 

interface 


type  Throov;ay  is  represented  by 

ffl  :  Flipflop 
ff2  :  Flip flop 

end  representation 
exemplar  tv;_rcp 

correspondence  tw  =  1  *  PARITY ( tw„rcp . ffl . state)  + 

2  *  PARITY ( tw„rcp . f f 2 . state ) 

procedure  Advance  (t  :  Threev/ay)  is 

begin 

Toggle  (t.ffl) 
if  not  Test (t.ffl)  then 
Toggle  (t.ff2) 
end  if 
end  Advance 

function  On  (t  :  Threev/ay)  :  Boolean  is 

begin 

return (Test (t. ffl)  or  Test(t.ff2)) 

end  On 


e  nd  C I  _'i  h  r  e  c v; a  y _  1 


‘i.7:  C’oncrotf'  Iiistaiu'f'  CI_Threeway_l 


Cl  _F1  ipf  lop_3  is  us('fl).  (Ik^  c*()i'r('S])()iKl('ii(*r'  must  Ix'  df'fiiic'd  in  t('riiis  of  tin'  Flipflop 
r(‘l)re>(‘iitation  providtxl  hy  CI_Flipf lop_3. 

l  iyun^  3.8  shows  (‘oiicnd InnpUitr  CT_Threeway„l.  an  alt(M’nativ('  ini])l('nionta- 
tinii  of  AI_Threeway  that  prc^scaits  an  ('xaniph'  of  the  needs  iidat ionshij).  Instead 
of  de])faidinu  on  a  six'x'ific  fli])-flo])  ini])Ic'nientation,  CT_Threeway_l  is  parainoteri/ed 
In-  a  eoner('t(‘  instance  that  implements  AI_Flipflop.  Tin'  dc'h'rn'd  (h'pcauh'iiev  of 
CT„Threeway_l  on  soinf'  (r/;///)  iin])l{Mnentation  of  AI_Flipflop  is  ex])ressed  hv  tlu' 
needs  elaiisf^  at  thf'  end  of  tln^  context  sen  ion.  Any  eoinponent  that  inelndes  oik^  or 
more  needs  rlaiis(‘s  in  its  context  section  is  a  teniplat(\  TIh^  id(aitifier  CI„Flipflop 
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implementation  CT_Threeway_l 
implements  AI__Threeway 

context 

uses  AI_Flipflop 

needs  CI_Flipflop  implementing  AI_Flipflop 

auxiliary 

math  operation  BTI  (B  :  BOOLEAN)  :  INTEGER 

definition  if  B  then  1  else  0 

interface 

type  Threeway  is  represented  by 

ffl  :  Flipflop 
ff2  :  Flipflop 

end  representation 
exemplar  tw_rep 

correspondence  tw  =  1  *  BTI ( tw_rep . f f 1 )  +  2  *  BTI ( tw_rep . f f 2 ) 

procedure  Advance  (t  :  Threeway)  is 

begin 

Toggle  (t.ffl) 
if  not  Test (t.ffl)  then 
Toggle  (t.ff2) 
end  if 
end  Advance 

function  On  (t  :  Threeway)  :  Boolean  is 

begin 

return (Test (t . ffl)  or  Test(t.ff2)) 

end  On 

end  CT_Threeway_l 


Figure  3.8:  CT_Threeway_l  needs  AI_Flipf  lop 


in  the  needs  clause  is  a  formal  parameter  name  representing  the  concrete  instance 
supplied  as  an  actual  parameter  when  CT_Threeway_l  is  instantiated.  Note  that  the 
needs  clause  presented  here  is  very  similar  to  the  needs  clause  of  Goguen’s  Library 
Interconnection  Language  (LIL)  [Gog86,  p.  22]. 

CT_Threeway-l  has  a  fixed  dependency  on  AI_Flipf  lop  as  indicated  by  the  second 
uses  clause  in  the  context  section.  CT_Threeway_l  uses  AI_Flipflop  to  specify  the 
behavioral  requirements  of  any  concrete  instance  supplied  as  an  actual  parameter. 
AI_Flipf lop  also  provides  the  model  for  type  Flipflop  and  behavioral  specifications 
for  operations  Toggle  and  Test  used  in  CT -Threeway _1.  Therefore,  no  matter  how 
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Fi.min'  3.9:  CT_Threeway_l  needs  AI_Flipflop 


CT_Threev7ay_l  is  iiislfiiitiatcd.  it  is  jjossihlc  to  reason  al)oiit  iIk'  Ix'liavior  of  tlie 
coiicrcte  iiistatua'  _t;eiierat ed  in  teniis  of  AI^Flipflop.  In  particnlar.  it  is  ])ossil)le 
to  justify  tlie  claitn  that  r;/;//  instatiee  of  CT_Threeway_l  implements  AI.Threeway 
wliich  is  tli('  claim  e.\])ressf’d  in  the  first  line  of  hi^nie  3.8.  dims  this  is  an  exaniph’ 
of  the  second  form  of  implements  listc'd  on  i)a';('  10. 

d  he  interface  seetittti  of  CT.Threeway_l  is  identical  to  that  of  CI_Threeway_l 
exee])t  fm  the  correspondence  (danse,  d  he  eorrespond('nee  is  difien'iit  Ix'cansc'  the 
rei)resentation-lev(d  mod(d  of  t\p('  Threeway  (hdined  in  CT-.Threeway_l  is  diflerent 
frotn  that  of  tyja'  Threeway  defined  in  CI-Threeway_l.  Tin'  mathematical  mod(d 
of  type  Flipflop  used  in  CT_Threeway_l  is  BOOLEAN  as  sjaxific'd  in  AI.Flipflop. 
Ihcrefore  the  r('pres('nt at ion-lev(d  nuxhd  of  ty]x'  Threeway  (hdiiu'd  in  CT_Threeway_l 
is  a  ])air  of  BOOLEAN  ohjects.  ddie  correspondence  (danse  ns('s  the  math  ()p('ration 
BTI  { Boolean- ]o-lntey,er)  to  con\'ert  FALSE  to  0  and  TRUE  to  1.  The  r(dation  dehtuxl 
hy  the  correspotidetic('  maps  tlx'  four  r('|)resentat ion  stat('s  to  tlx'  four  abstract  stat('s 
defined  iti  AI.Threeway.  lor  exam])l('.  any  representation  for  \vhi(h  values  of  both 
flip-flol»  correspotid  to  TRUE  ma])s  to  the  abstract  stat('  3  \vhi(di  nxxhds  tlx'  s\vit(di 
in  the  'diiyli "  position. 

1' iynre  3.9  shows  a  comjjonent  eonplin.u;  diagram  depicting  tlx'  implements  and 
needs  relationships  ('ixodcd  by  CT_Threeway_l.  ddx'  needs  r(dationshi])  is  d('pict(’(I 
by  a  thi(d\  solid  arrow  frotn  ;i  e()ticr('te  eom]x)n('nt  to  an  abstract  e()m])on(’nt.  Xote 
that  the  uses  relationship  betw('('n  CT.Threeway_l  and  AI_Flipflop  is  not  shown 
since  a  needs  ladationshi])  always  implies  a  uses  ndationship. 


Since  CT_Threeway_l  is  a  concrete  template,  it  must  be  instantiated  in  order  to 
describe  the  behavior  of  a  concrete  instance  that  may  be  integrated  into  a  component- 
based  system.  In  this  case,  instantiating  CT_Threeway_l  requires  selecting  a  compo¬ 
nent  that  implements  AI_Flipflop  to  fulfill  the  stated  need.  The  code  describ¬ 
ing  an  instantiation  of  CT_Threeway_l  with  the  CI_Flipf  lop_3  implementation  of 
AI_Flipflop  is  as  follows. 


implementation  CI_Threeway  implements  AI_Threeway 

by  CT_Threeway_l  with  (CI_Flipflop  =>  CI.Flipf lop_3) 

The  name  CI_Threeway  refers  to  the  concrete  instance  resulting  from  the  instan¬ 
tiation  of  CT.Threeway.l  with  actual  parameter  CI_Flipf  lop_3  bound  to  the  formal 
parameter  CI_Flipflop.  The  instantiation  explicitly  states  that  CT_Threeway  im¬ 
plements  AI-Threeway  which  follows  from  the  implements  relationship  between 
CT_Threeway_l  and  AI.Threeway.  Therefore  we  may  reason  about  the  behavior  of 
the  code  using  CI.Threeway  in  terms  of  the  specification  provided  by  AI_Threeway. 
In  this  example,  the  behavior  implemented  by  CI_Threeway  is  identical  to  the  behav¬ 
ior  described  by  CI_Threeway_l  shown  in  Figure  3.7.  As  a  result  of  this  instantiation, 
only  the  program  elements  described  by  AI-Threeway  are  visible  to  clients  of  the  in¬ 
stantiation  CI-Threeway.  Thus  this  single  instantiation  serves  two  distinct  purposes. 
First  it  “fills  in  the  holes”  of  CT_Threeway_l  to  create  a  usable  concrete  instance, 
CI_Threeway.  Second,  it  associates  with  this  concrete  instance  the  abstract  interface 
AI_Threeway  that  describes  how  clients  should  view  CI_Threeway  and,  in  fact,  the 
only  program  elements  defined  in  CT_Threeway_l  that  are  available  for  use  by  client 
code. 

Using  the  model  developed  in  Chapter  2,  we  describe  the  meaning  of  CI.Threeway, 
the  component  described  by  the  above  instantiation,  as  follows.  CI_Flipf  lop_3  and 
CI-Threeway  are  members  of  Cl  and  CT_Threeway_l  is  a  member  of  CT.  The  be¬ 
havior  implemented  by  CI.Threeway,  «S(CI_Threeway),  is  modeled  by  the  element  of 
B  given  by  5(CT_Threeway_l)(tS(CI_Flipf lop_3)). 

As  we  noted  at  the  beginning  of  this  section,  a  concrete  template  may  have  de¬ 
ferred  dependencies  on  implementations  of  more  than  one  abstract  component  and 
may  even  have  multiple  independent  dependencies  on  the  same  abstract  compo¬ 
nent.  For  example,  it  would  be  possible  for  a  different  concrete  template  imple¬ 
menting  AI.Threeway  to  have  two  needs  clauses  in  the  context,  one  naming  CIJ'F.l 
and  the  other  naming  CI_FF_2,  both  representing  concrete  instances  implementing 
AI_Flipflop.  Then  the  two  fields  ff  1  and  ff2  representing  the  type  Threeway  could 
be  declared  of  types  CI_FF_1  .Flipf lop  and  CI_FF_2.Flipflop.  In  this  case  instan¬ 
tiation  of  the  concrete  template  implementing  AI.Threeway  would  require  two  actual 
parameters,  both  implementing  AI_Flipflop.  The  actual  parameters  might  be  the 
same  concrete  instance  or  two  different  implementations  of  AI_Flipf  lop.  Clearly  this 
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simple  (’x;uii])l('  picseiils  Hi  tie  motivation  for  tisiiiL!,  two  (lifl(’reiit  im])lemeiitatioiis  of 
AI-Flipflop.  I loW('\('i‘.  Sitaramaii  disciissc's  how.  in  gcmeral.  such  a  strat(’i!,\'  is  useful 
for  ])erformanc(>-i)arameteri/e(l  compoiK'iits  [Sitn2]. 

3.4.2  Spocification-Level  needs 

On  pa'i<‘  1)  we  listf'fl  thrc'c'  distinct  relat ionslii])S  to  which  w('  ajiplv  tlu'  ovculoaded 
K'rm  implement.s.  The  implements  relationshii)  Ix'twt'cn  a  concrete  instance  and 
an  ahstrart  instance  was  exemplified  hy  CI.Flipf lop_3  imidementinn  AI_Flipflop. 
The  implements  relationship  Ix'twec'ii  a  concrete  Irinpldli  and  an  ahstract  instance 
wa-  exemplified  hy  CT_Threeway_l  im))lementinn  AI.Threeway.  We  are  now  ready 
to  discuss  an  exam])le  of  th('  third  form  of  implements,  a  concret('  template'  im])le- 
nientinu  an  ahstract  template. 

fiyure  .3.10  shows  the  encoding  of  ahstract  tc'inplate'  AT_Stack.  a  hehavioral  inter¬ 
face'  spe'e  ifie  atiein  feer  a  stae'k  whie  h  is  ee'iie'rie-  with  re'spe'e’t  tee  the  type  of  ele'inents  it 
ma\  eoiitain.  AT.Stack  has  a  de'fe'i  re'el  ele'])e'uele'ne'y  een  the'  t\  ])e'  e)f  ('h'lnents  ceentaine'd 
in  the'  stae'k.  .-\n  insi ant iat ieeii  eef  AT_Stack  nee-ds  an  im|)le'me'nt atieen  of  a  S])ee'ifie' 
tyjee'  to  se-rve'  as  the'  tyjee  eef  ele'ments  ceeiitaitu'd  within  the'  stae-k",  AT.Stack  uses 
AI-AnyType.  a  sjee'eial  ahstract  instane'e'.  tee  ('X])re'ss  its  re'ejuire'ine'nt  feer  a  ceempement 
l)ro\'iehny  a  type'.  AI.AnyType  is  spe'e'ial  in  that,  hy  ceenveni ieen.  ('\‘e'ry  ceene'ie'te’  in- 
stanee'  that  eh'fine's  at  h'ast  eene  type'  implements  AI_AnyType.  AI.AnyType  name's 
a  sineh'  type.  AnyType.  whie'h  has  nei  assoe-iate'd  mat he'mat ie-al  meedel.  Whe'n  an 
ahstraet  te'ni])late'  that  lu'e'ds  an  inpele'me'ntat ieui  of  AI.AnyType  is  instantiate'el.  the' 
mat  he'mat  ical  meeeh'l  of  the'  e'eenere'te  ty])e  that  corre'sjeeeiiels  tee  AnyType  is  tise'el  tee 
eh'.se'i ihe'  the'  math  iiieeele'l  eef  the'  re'sult iny  instane'e'.  If  the'  ceempeenent  se'iviny,  as  the' 
aefiial  learanu'te'r  eeirre'speendin.y  tei  AI_AnyType  (h'fine's  more  than  euie'  t>i)e'.  the'ii  the 
,///.</  tyjee'  ch'fine'd  is  mate'he'el  tee  AnyType.  (.\  t>pe'  othe'r  than  the  first  tyjee'  de'fine'el 
hy  a  eeme-re'te'  instanee'  may  he'  mate'he'el  with  AnyType  hy  using  an  ahstrae't  instane'e' 
to  "mask  out"  all  hut  the'  de'sire'el  ty|)e'.) 

In  AT.Stack.  the'  name'  AnyType  re'pre'se'uts  the'  type'  supidie'd  hy  the  cennpone'iit 
whieh  se'r\e’s  as  the'  ae'tinil  |)aramete'r  e'eerre’speending  to  CI_StackIteinType  in  an  in- 
stantiaiion  e)f  AT.Stack.  In  the'  auxiliary  se'ctieen.  the'  learame'te'iize'd  math  meecluh' 
f'lT.String. Theory  is  instantiate'd  tee  preeelue'e'  the'  math  meeeluh'  MI.String.Theory 
whieh  (h'fine'.s  the'  math  type'  STRING  tise'd  te)  meede'l  a  stae'k.  1  he'  feermal  (type')  pa- 
rame'fer  ItemType  eef  MT.String.Theory  re'iue'se'nts  the'  math  tyj)e'  eef  the'  elements 
eef  the-  math  ty])e'  STRING.  1  hus.  feer  ('xamph'.  if  AT.Stack  we'ie  instantiate'd  with 
Cl.Integer.l  as  the'  aetual  paranu'te'r  fe)r  CI.StackItemType.  math  type'  STRING 
woiilel  re-fer  tei  a  String  e»f  math  type'  INTEGER.  In  this  instane'e'.  the'  mathe'inatie'al 
meeeh'l  eef  Stack  weeiihl  he-  a  String  eef  INTEGER  value's. 

'■  III''  stark  S])rrifi('il  ill  I-igurc  is  ;i  luiniofiriiroiis  stark.  Tliat  is.  all  e'lcine'iits  in  insteinccs  eef 
the-  sprrified  stark  ;irr  iilijcrts  eef  a  single  fixed  lv|ie. 
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specification  AT_Stack 
context 

uses  MT_String_Theory 
uses  AI_AnyType 

needs  CI_StackItemType  implementing  AI_AnyType 

auxiliary 

math  module  MI__String_Theory  is  MT_String_Theory 
with  (StringItemType  =>  AnyType) 


interface 

type  Stack  is  modeled  by  STRING 
exemplar  s 

initially  s  =  EMPTY_STRING 

procedure  Push  (s  :  Stack,  x  :  AnyType) 
ensures  s  =  #s  *  <x>  and  x  -  #x 

procedure  Pop  (s  :  Stack,  x  :  AnyType) 
requires  s  /=  EMPTY_STRING 
ensures  # s  =  s  *  <x> 

function  Length  (s  :  Stack)  :  Integer 
ensures  Length  =  I s | 

end  AT_Stack 


Figure  3.10:  Abstract  Template  AT.Stack 


The  interface  section  of  AT_Stack  defines  the  program  type  Stack  and  three 
operations:  Push,  Pop,  and  Length.  As  noted  above,  type  Stack  is  modeled  by  a 
mathematical  string  of  elements.  The  initial  value  of  a  Stack  object  is  modeled 
by  an  empty  string.  The  (constant)  math  operation  EMPTY-STRING  is  provided  by 
MI_String_Theory.  The  post-condition  of  Push  specifies  that  after  the  Push  operation 
completes,  the  new  value  of  the  stack  (s)  is  modeled  by  the  old  value  of  the  stack 
(#s)  concatenated  with  (*)  the  singleton  string  containing  the  element  pushed  onto 
the  stack  (<x>).  Also,  the  value  modeling  the  element  being  pushed,  is  the  same 
before  and  after  the  operation  (x  =  #x)^^.  Pop’s  requires  clause  specifies  the  pre¬ 
condition  that  the  stack  not  be  empty.  Pop’s  ensures  clause  specifies  that  after  the 

^-The  post-condition  of  Pop  in  a  RESOLVE-style  stack  interface  does  not  require  that  the  element 
being  pushed  is  unchanged.  We  discuss  the  RESOLVE  approach  in  the  context  of  a  queue  component 
in  Section  5.2. 
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Pop  (iprratioii.  tli('  now  valiu'  of  the  stack  (s)  coiicat ('iiat ('d  with  the  sinsh'ton  striiic; 
ooiitainine  the  (>loinont  ])()])])0(1  from  the  stack  (<x>)  will  Ix'  the  same  as  the  ohl  value' 
iiiofh'liiiu  ih('  stack.  The  Length  operation  is  a  function  which  n'tnrns  the'  lem;th  of 
th  «'  stack,  modeled  hv  the  length  of  the  sti'ing  repre'se'nting  the  stack  (|sl). 

figure  3.11  shows  the  encoding  of  concrete'  te'inplale'  CT_Stack_l  whieT  prewieh's 
an  imple'ine'iitatieen  of  the  he'havieer  sjie'e'ifie'el  hy  AT_Stack.  CT_Stack_l  has  two  de'- 
fe'rre'el  de'])e'nele'ne-ie's.  f'iisl.  it  ne'e'fls  an  im])le'me'ntatie)n  e)f  AI^AnyType  tee  pren  ieh'  the' 
type'  eif  e'le'ine'iils  tei  he'  e'e iiit aine'el  in  the'  stae'k.  Se'e'eenel.  it  ne'e'ds  an  imple'inentat ieen 
e)f  <m  iiistducf  of  AT_One_Way_List  that  has  he'e'ii  instant iate'd  with  the'  same'  ceeii- 
e'le'te'  insfane’e'  supplie'el  as  the'  first  ])arame't e'r.  the'  ae'tual  jearanu'te'r  e'orre'S])e)nding  tee 
Cl  _StackItemType.  1  he'  list  imple’ine'nt  at  ie)n  su])])lie'el  as  t  he'  see'eeiiel  para me't e'r  is  iise'd 
a^  the'  stae-k  re'])rese'nt at ietii.  AT_One_Way.List  s])ecifie'.s  a  ge'iieiic  list  whieh  is  me)ele'leel 
hy  a  pair  eef  STRING  value's,  a  h'ft  string  anel  a  right  string,  heeth  initially-  empty.  The' 
in>e'rtion  anel  re'ineeval  peeint  fe»r  e'le'ine'iits  in  the'  list  is  the'  le'ftniost  e'le'inent  eef  the  right 
string.  A  meere'  eh'taih'el  de'se  ripl ieen  eef  the'  One_Way-List  s])e'e  ificatie)n  mav  he  feeund 

in  swiind;. 

I  he'  eipe'iatieens  Push.  Pop.  anel  Length  are'  imiele'inente'el  trivially  hy  e-alling  the' 
list  eeiee'ialie.ns  Aeid_Right.  Remove _Right.  anel  Right.Length  re'sjee'e't ive'lv.  This  im- 
ph'me'ntatie)!!  eeiily  use's  the'  right  string  eef  the'  list  which  grows  tee  the'  hfi  as  e'le'inents 
ai'c  aeleled.  Sine'e'  Stack  is  mexh'le'el  hy  a  string  that  greews  tee  the'  riijlii  as  eh'inents 
are'  pushe'el  onte)  it.  the'  correspondence  e-lause'  state's  that  the  right  string  moelel- 
ing  the'  stjie  k’s  list  re'jere'se'nt at ieeii.  wlie'ii  reve'r.sefl.  (•e)rre's])e)nds  tee  the'  string  meede'ling 
the'  stae'k.  Note'  that  the'  math  eipe'iatie)!)  REVERSE  is  eh'fine'el  in  MT_String_Theory 
anel  is  avaihihle'  for  use'  he'ie'  eeiily  he'e-ause'  CT_Stack_l  uses  AT_Stack  whie'h  uses 
KT.String.Theory. 

fiiture'  3.12  is  a  C'C'l)  sheewing  the'  he'lnivieertil  re'lat iettishijts  hetwe'e'ti  CT-Stack_l. 
AT_Stack  anel  the'  eethe'r  e'e)m])e)ne'tits  ttpeeii  whie'h  it  elire'ctly  ele'pe'iiels.  Ne>  uses  re'la- 
tie)nshi])S  are  sheewti  sine'e'  tlu'se'  ;tre'  im])lie'el  hy  the'  needs  re'hitieeiiships.  Alset.  we  dee 
iieit  sheiw  de'pe'iiele’ncie's  eiii  e'eetnpeitients  |)re)vieling  huilt-in  type's  sueh  as  CI.Integer_l 
whieh  eh'fitie's  the'  tyjee'  Integer  re'tnrne'd  hy  the'  Length  fune'tieen. 

We  e  hiim  tluit  CT_Stack_l  implements  AT_Stack  hy  the'  thirel  de'fitiitie)n  e)f  im¬ 
plements  (e)n  page'  fG).  Th;it  is.  feer  any  instantiatieen  C  etf  CT_Stack_l  tlu're'  e'x- 
i>t>  soon  instantiatieen  7  eef  AT^Stack.  sue'h  that  impsfT'.  7  )  heelels.  In  this  case', 
if  the'  satiH'  e-one  re'te'  insttme'e'  is  sn])|)lie'el  as  the'  ae'tual  paratnete'r  ('e)rre'si)e)nding  tee 
CI.StackItemType  feer  heuh  AT_Stack  anel  CT.Stack.l,  the'ii  the'  e'euierete'  instatice 
ele'serihe'el  hy  the'  itist ant iat ieeii  e)f  CT_Stack^l  will  implement  the'  ahstrae-t  instatie-e 
ele'>e'rihe'el  hy  the'  itist;inti;itie)n  e)f  AT.Stack. 

figure'  3.13)  shows  the'  eexh'  for  twe)  itist ant iatieitis  tiseel  tee  generate  a  stack  eef 
flil)-f!ops.  The'  first  inst ant i;it ieen  eh'serihe's  the'  e-etne're'te'  instatice  CI^Flipf lop.List 


implementation  CT_Stack_l 
imp  1  emen  t  s  AT_S  tack 

context 

uses  AI_AnyType 
uses  AT_On  e_Way _L i s  t 

needs  CI_StackItemType  implementing  AI_AnyType 
needs  CI_List  implementing  AT_One_Way_List  with 
(CI_ListItemType  =>  CI_StackItemType) 


interface 

type  Stack  is  represented  by 
holder  :  List 
end  representation 
exemplar  s_rep 

correspondence  s  =  REVERSE ( s_rep . holder . right ) 

procedure  Push  (s  :  Stack,  x  :  AnyType) 

begin 

Add_Right (s .holder) 
end  Push 

procedure  Pop  (s  :  Stack,  x  :  AnyType) 

begin 

Remove__Right  (s  .holder) 

end  Pop 

function  Length  (s  :  Stack)  :  Integer 

begin 

return  ( Ri ght _Leng t h ( s . ho 1 der ) ) 
end  Length 

end  CT_Stack_l 


Figure  3.11:  Concrete  Template  CT_Stack_l 


which  implements  the  behavior  specified  by  the  abstract  instance  generated  by  in¬ 
stantiating  AT_One_Way_List  with  concrete  instance  CI_Flipf lop-3  (shown  in  Fig¬ 
ure  3.5).  The  implementation  of  CI_Flipf  lop_List  is  provided  by  the  instantiation  of 
CT_One_Way_List_l  with  CI_Flipf  lop_3.  The  concrete  instance  CI_Flipf  lop.Stack 
is  generated  similarly.  It  implements  the  abstract  instance  formed  by  instantiating 
AT.Stack  with  CI_Flipf lop_3.  The  implementation  of  CI_Flipf lop_Stack  is  pro¬ 
vided  by  instantiating  CT_Stack_l  with  CI_Flipf  lop_3  serving  as  the  element  type 
and  CI-Flipf  lop_List  serving  as  the  list  implementation  used  to  represent  the  stack. 
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implementation  CI_F1  ipf lop__List 
implements  AT_Ono__Way_List  with 

(CI„List:  I  tcmTypc  =>  CI_F1  ipf  lop_3  ) 
by  CT_Or.c„V7ay_Li st_l  with 

(C:_List I tcmTypc  =>  CI_Fl ipf lop„3 ) 

implementation  CI_F1 ipf lop_Stack 
implements  AT_St:ack  with 

(CI_Stack I tcmTypc  =>  CI_F1 ipf lop_3 ) 
by  C7_St:ack_l  with 

(CI_Stack I tcmTypc  =>  CI_F1 ipf lop_3 , 

CI_List  =>  CI_Flipf lop„Li  St ) 


I*  3.13:  InslMTitiation  of  CT_Stack_l 


I  hr  needs  i'(3aT ionslii])  hf'twcH'ii  an  iinplcniuMitation  and  a  s])ocificati()n  rxprossf^s  a 
l)f>h/ji)r>rplnr  p'la t ioiislii] ).  Many  (lifff'n'iit  ‘'forms*'  or  inipl(Miirntations  of  the  abstract 
c(nnponcnt  opm-ations  may  !)('  nscvl  l)y  tln^  ol)j('cts  (l(H*larofl  fi'oi]i  instances  of  the  con- 
cr(Tf'  com])nn(Mit.  J  an'  two  primary  st ratc'gic's  for  encoding  this  polymorphism 
in  ])rogramnhng  langnag('s.  ( )l)j('ct-ori('nt('d  discipline's  ty])ically  use  in}}rrif(inrr  and 
(hpifjinir  hnidnifj  to  achie've'  ])olymorphisin.  Tlu'  notation  iise'd  in  this  chaptf'r  uses 
paranif't ('I'i/at ion  and  static  binding.  HF^SOIA  F/AdaDT),  diseaisse'd  in  Chapte'r  5  use's 
f\  e  ( »mbi na t if )n  of  paranie'te'ri/atie)n  and  inhe']atane*('.  Se'e’tie)n  4.2  di.se’usse's  pi'ogram- 
minu  laneiiate'  su])])ort  for  ('X])r('ssing  the'  needs  r('latie)nship.  In  the'  ne'xt  see-tie)n 
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we  discuss  the  benefits  of  designing  components  using  the  implements  and  needs 
relationships. 

3.4.3  Integration  Dependencies  Versus  Design  Dependencies 

Recall  from  Chapter  1  the  difference  between  design  dependencies  and  integration 
dependencies.  A  component’s  design  dependencies  exist  independent  of  any  particular 
use  of  the  component.  A  component’s  integration  dependencies  are  the  dependencies 
it  has  on  other  components  once  integrated  into  a  component-based  system.  The 
uses  relationship  between  concrete  instances  naturally  expresses  integration  depen¬ 
dencies  and  also  may  express  fixed  design  dependencies.  For  example,  the  relationship 
CI_Threeway_l  uses  CI_Flipf  lop-3,  as  encoded  in  Figure  3.7,  expresses  a  fixed  de¬ 
sign  dependency.  The  needs  relationship  may  be  used  to  express  design  dependencies 
as  deferred  dependencies.  The  relationship  CT_Threeway_l  needs  AI_Flipflop,  as 
encoded  in  Figure  3.8  and  depicted  in  Figure  3.9,  expresses  a  deferred  design  depen¬ 
dency.  Building  a  system  from  concrete  templates  with  deferred  dependencies  may 
require  more  effort  than  building  a  system  from  (pre-existing)  concrete  instances  with 
only  fixed  dependencies,  since  templates  must  be  instantiated.  However,  as  we  dis¬ 
cuss  below,  using  needs  relationships  instead  of  uses  relationships  to  express  design 
dependencies  can  significantly  improve  the  understandability,  maintainability,  and 
reusability  of  components. 

Figure  3.14  shows  three  different  views  of  the  same  component-based  system,  each 
emphasizing  a  different  component  relationship.  Figure  3.14(a)  is  the  same  diagram 
shown  in  Figure  2.8  and  explained  in  Section  2.4.1.  The  arrows  represent  the  (direct) 
uses  relationships  involving  these  five  concrete  instances.  The  arrows  shown  in  Fig¬ 
ure  3.14(b)  represent  the  needs  relationship.  This  diagram  shows  that  concrete  tem¬ 
plate  AIT  needs  a  component  that  implements  the  behavioral  specification  B  and  one 
that  implements  the  behavioral  specification  C.  In  the  system  shown,  instantiations 
of  BIT  and  CIT  satisfy  these  requirements,  respectively.  BlT’s  requirement  for  imple¬ 
mentations  of  D  and  E  and  ClT’s  requirement  for  an  implementation  of  E  are  satisfied 
by  implementations  Dl,  El,  and  El,  respectively.  The  arrows  in  Figure  3.14(c)  repre¬ 
sent  the  implements  relationship  and  also  the  template  instantiations  necessary  to 
build  the  system.  This  view  conveys  exactly  the  same  information  as  Figure  3.14(b), 
but  more  clearly  depicts  AIT,  BIT,  and  CIT  as  templates  with  “holes”  to  be  filled  in. 

Figure  3.14(a)  is  a  traditional  structure  chart  that  shows  which  parts  of  the  sys¬ 
tem  depend  on  which  other  parts.  It  does  not,  however,  provide  any  information 
about  the  role  played  by  each  component  or  what  the  options  might  be  for  compo¬ 
nent  replacement.  Figure  3.14(b)  and  (c)  convey  more  information  useful  to  system 
maintainers  and  component  composition  tools.  These  diagrams  provide  information 
about  the  roles  played  by  each  sub-component  of  the  system  (although  no  system- 
level  specification  describing  the  behavior  of  AIT  is  shown).  By  depicting  external 
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(a)  uses  (b)  needs 


(c)  implements 


I  '{.11:  'J  lir('('  \’i(nvs  Of  The  Satiu'  Syst('in 


(l(‘])f’n(lciK  i('.s  of  AIT.  BIT.  and  CIT  at  llu'  sjx'cificat ion  l('V('l.  Fi.yiirrs  .3.1  1(1))  aiul  (c) 
identify  K'fiiiirc'inonts  for  conipoiu'tits  that  ini,!;iit  replace'  BIT.  CIT.  Dl.  or  El. 

C'onsifler  an  exani])le  of  how  the  system  in  h'ieun'  .'{.1-1  might  he  modified.  A.ssiiim' 
that  the  s\>teni  p('rformane('  lu'eds  to  Ix'  imieioved  and  that  analysis  determines  that 
eom])()nent  El  is  a  l)oItleneek.  The'  figure  shows  that  BIT  and  CIT  both  dejeend  on 
(nnj  eonen'tf'  instance  that  implements  E.  not  s])erifieally  on  imph'inentation  El. 
dims.  aiK)ther  comporn'iit  that  implements  E.  say  E2.  can  Ix'  siihst itiited  for  El  in 
this  system  witlxxit  n'finiriiig  ehangt's  to  any  of  tlx'  other  components.  PresumahK' 
replacing  El  with  E2  would  yield  better  system  ])erformance  diu'  to  differenct's  Ix'tweeu 
th  e  twii  imj)l('inentations  not  conslraiiu'd  by  E. 

-As  another  example,  implementation  Dl  might  .st'i  ve  as  an  interface  to  tlie  system's 
envirotinient.  That  is.  Dl  might  intt'iacl  dirt'ctly  with  operating  .systt'in  software  or 
hardware.  If  the  system  needs  to  Ix'  rehosted  to  a  new  ('mironim'iit.  then  com])o- 
nent  Dl  might  need  to  be  r('])lac('d  with  another  implementation  providing  the  same 
behavior  tis  specifii'd  by  D.  but  imjtleuK'nt ing  tlx'se  servict's  differt'iitly  in  ordt'r  to 
interaet  with  a  differt'tit  environment.  In  this  case,  another  com])onent.  say  D2.  that 
interacts  with  the  new  environux'nt  and  which  iinplcniciifs  D  could  Ix'  substitutt'd  for 
Dl  without  reciuiring  chatiges  to  other  cotnjtom'iits  in  tlx'  system. 

We  saicl  that  (-ach  of  the  thrt'e  diagrams  in  Figure  -3.1 1  depicts  tlx'  sanx'  sperifir 
s\steni  composed  of  livt'  compom'uts.  I-or  this  to  lx*  the  case.  B1  must  denote  the 
com])onent  gt-nerated  by  instantiating  BIT  with  Dl  aixl  El.  Cl  must  denote  the  com- 
pfiiient  gt'iK'rated  by  instantiating  CIT  with  El.  <uid  A1  must  denote  tlu'  component 
(or  top-level  program  unit)  generated  by  instantiating  AIT  with  B1  and  Cl.  In  this 
ca<e.  IIOIU'  of  the  fi\e  integration  de|x'nd('m  ies  shown  in  Figun'  3.1 1(a)  necfl  be  (h'sign 
de])endenr'ies.  1  liat  is.  prior  to  instantiation  of  BIT.  tlx'it'  ma\’  Ix'  no  com])onent  B1 
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that  specifically  depends  on  D1  and  El.  If  the  system  were  developed  from  compo¬ 
nents  in  a  component  library,  then  the  library  might  contain  the  components  AIT, 
BIT,  CIT,  Dl,  and  El  with  design  dependencies  expressed  in  terms  of  implements 
and  needs  rather  than  in  terms  of  uses. 

Software  engineers  generally  want  to  avoid  any  unnecessary  dependencies  (cou¬ 
pling)  between  components.  The  needs  relationship  between  an  implementation 
and  a  specification  may  be  applied  to  achieve  this  goal.  Figure  3.9  depicts  the 
needs  relationship  between  the  implementation  CT_Threeuay_l  and  the  specification 
AI_Flipflop.  In  this  case,  the  description  of  the  three-way  switch  implementation 
only  depends  on  the  abstract  description  of  a  flip-flop  (provided  by  AI_Flipf  lop). 
During  program  execution,  an  object  declared  from  an  instance  of  CT_Threeway_l 
will  indeed  depend  on  some  specific  implementation  of  AI_Flipf  lop. 

Fully  understanding  the  non-functional  characteristics  of  this  object  would  in¬ 
clude  understanding  the  non-functional  characteristics  of  the  specific  flip-flop  imple¬ 
mentation  used.  However,  to  understand  and  reason  about  the  functional  behavior 
described  by  an  instance  of  CT_Threeway_l,  it  is  sufficient  to  understand  the  behavior 
described  by  AI_Flipf  lop  and  AI.Threeway  (assuming  CT_Threeway_l  implements 
AI_Threeway  as  claimed). 

3.5  The  extends  Relationship 

Once  a  software  system  has  been  designed  and  implemented,  changes  to  require¬ 
ments  are  likely  to  call  for  improved  performance  and  functionality.  Improvements 
in  performance  which  do  not  alter  functionality  may  be  addressed  by  replacing  one 
concrete  component  with  another.  This  section  describes  the  extends  relationship 
which  is  useful  for  adding  new  functionality  to  existing  components. 

If  component  designers  had  perfect  foresight  they  might  be  tempted  to  design 
components  with  all  the  functionality  that  clients  could  ever  want.  If  this  were  possi¬ 
ble,  then  implements,  needs,  and  uses  might  be  sufficient  for  describing  component 
relationships.  Unfortunately,  component  designers  do  not  have  perfect  foresight.  No 
matter  how  much  forethought  designers  apply,  new  requirements  almost  always  ex¬ 
pose  some  desirable  and  unforeseen  functionality.  Clearly  w^e  need  some  method  for 
extending  the  functionality  of  components  already  in  use. 

Lack  of  perfect  foresight,  however,  is  not  the  only  reason  for  providing  a  means  to 
extend  the  functionality  of  components.  Some  disciplines  for  designing  components 
advocate  providing  a  wide  assortment  of  possibly  useful  operations  in  each  individual 
component  [Mey94] .  The  problem  with  this  approach  is  that  the  resulting  interfaces 
are  more  complex  and  thus  more  difficult  for  clients  and  component  implementers 
to  understand.  Furthermore,  this  approach  either  leads  to  code  bloat  resulting  from 
many  unused  operations  or  requires  assumptions  about  optimizations  which  attempt 
to  expunge  the  code  of  unused  operations.  One  reasonable  approach  is  to  design 
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(■(iiiiixiiu’iiis  witli  a  iiiiiiiiiially  snHi(  i(’iit  s('t  of  ojx'rations  which  hw  a  foiiiirlation  upon 
which  future  ('uhaucciuciits  may  l)c  coustruct('(i.  \\  ha1(’\’('r  initial  a])j)roach  is  used, 
liowcvcr.  cnhancc'incnts  to  functionality  art'  incvitahlc. 

3.5.1  Extension  Components 

lilt'  extends  relationship  is  a  behavioral  n'lationshi])  ht'tween  two  abstract  coin- 
IK.ncnts,  The  extends  rclationshi])  may  be  defined  informally  as  follows: 

.Abstract  ctunitoiient  ,4^  extends  abstract  com|)onent  .-li  if  and  only  if 
every  coiicrett'  coinixment  which  implements  A>  also  implements  .li. 

1  he  extends  rclationshi])  is  a  conformanct'  n'lationshi])  modt'h'd  by  tht'  exts  rela¬ 
tion  fh'hned  in  K(|uation  ‘i.-'b  Howt'vt'r.  likt'  imps,  exts  only  dt'seribes  a  rt'lation  over 
iintancf'  com])on('nts.  .As  wt'  did  with  implements,  wt'  overload  tht'  tt'rm  extends 
tt)  inclutle  rt'lationshi])s  invt)h  inx  tt'm])latt'  comjxtnt'iils.  We  ust'  the  ovt'rlt)atlf'tl  term 
"extends’  for  the  following  thrt't'  dislinci  rt'lationshi])s. 

•  If  .b  anti  .-b,  are  both  abstract  instanct's.  tht'ii  tht'  claim  that  .-b)  extends  .4) 
is  an  asst'i  tifui  that  extsf.  bj.  .4| )  httltls. 

•  If  .4;  i''  an  abstract  instance  and  .4_(  is  an  abstract  tt'm])latt'.  tlit'ii  the  claim  that 
.4_.  extends  .4i  is  an  asst'rtit)n  that  ftu'  fiin/  instantiat ittn  .4',  f)f  .4>.  extsf.lf,.  .4|) 

holtl>. 

•  If  .4;  aufl  .  bj  are  bt)th  abstract  templatt's.  tht'ii  tht'  claim  that  .bj  extends  .4i  is 
an  asst'rtion  that  for  (iinj  inslautiatittn  .4f,  of  .  Ij  there  t'xisls  soiiic  instatitiation 
.4'  t)f  .Ij.  such  that  extsf.  l',.  .4', )  holtls. 

We  discusN  an  exam])lt'  of  the  first  case  in  this  sectittn.  In  .St'ctittn  3.5.3.  we  discuss 
ati  cxam])le  of  tht'  thirtl  case,  f  he  st'ct)nd  cast'  is  inchttlt'd  ])ritnarih'  fttr  ct)m])lt'teness. 
We  are  nf)t  aware  of  any  nifttivat iti,i!;  exam])lt'.s  for  this  ft)rm  t)f  extends. 

In  Section  2.3.2  wt'  disciisst'd  ihret'  diflert'iit  ways  in  which  a  s])t'cification  ct)nij)o- 
nent  tniylit  be  extetitletl:  sjxriiilir^ai ion.  (icncniUrjifion.  anti  (iii(inj('nlfifion.  If  s])t'ci- 
fication  ct)m])ont'nts  are  j)aramt'ti'rizt'tl.  iht'ii  si)ecialization  t)f  .s])ecificatit)ns  may  be 
achieved  conveniently  throtiyh  tht'  instatitiatit)ti  t)f  abstract  lt'm])latt's.  If  s])t'cifica- 
tit)!!  com])otit'nts  art'  well-tlesi]2;ned  from  a  ct)m])ont'nt-b:ist'tl  rt'ust'  j)ers])ectivt'.  tht'ii 
tht'rc  shoiiltl  bt'  litth'  need  for  gt'iit'ializat ion  (wt'akt'iiiny  o])t'ratit)n  jue-ctuidit ions). 
I  hert'fore.  in  this  section  we  focus  on  ('xtension  by  auxmt'ntation.  lluit  is.  ('xtendiny; 
a  conptruient  by  athliny  new  o])t'ratit)ns. 

■As  a  sim])le  exani])lt'  of  tht'  extends  relat ionshi]).  ctuisidt'r  tht'  abstract  instance 
AI-Flipflop  shtiwn  in  l  iytirt'  .3.1  and  I  lit'  abstract  instatict'  AI.FFExt  shtiwii  iti  Fig¬ 
ure  3.1).  Wt'  claim  that  AI.FFExt  extends  AI_Flipflop  in  accortlatict'  with  tht'  first 
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specification  AI_FFExt 
extends  AI_Flipflop 

interface 

type  Flipflop  is  modeled  by  BOOLEAN 
exemplar  f  f 
initially  ff  =  FALSE 

procedure  Toggle  (f  :  Flipflop) 

ensures  f  =  NOT  #f 

function  Test  (f  :  Flipflop)  :  Boolean 

ensures  Test  =  f 

procedure  Set  (f  :  Flipflop) 

ensures  f  =  TRUE 

end  AI_FFExt 


Figure  3.15:  Abstract  Instance  AI_FFExt 


of  the  three  definitions  of  extends  above.  That  is,  any  concrete  instance  that  imple¬ 
ments  AI_FFExt  also  implements  abstract  instance  AI_Flipf  lop.  In  this  case,  as  is 
often  the  case  with  extension  by  augmentation,  it  is  easy  to  see  that  the  extends  re¬ 
lationship  is  justified.  The  only  difference  between  AI_Flipflop  and  AI_FFExt  (aside 
from  their  names)  is  that  AI_FFExt  includes  the  extends  clause  in  its  header  and  a 
specification  of  the  Set  operation.  The  extends  clause  plays  the  same  role  as  the 
implements  clause  discussed  in  Section  3.3:  it  records  design  intent  and  it  identi¬ 
fies  syntactic  and  semantic  conformance  checking  requirements.  The  specification  of 
procedure  Set  states  that  the  abstract  value  of  the  flipflop  passed  as  an  argument  is 
TRUE  after  execution  of  the  operation.  Thus  AI-FFExt  provides  the  same  type  and 
operations  as  AI_Flipf  lop  plus  the  additional  operation  Set. 

From  a  software  maintenance  perspective,  the  relationship  between  AI_FFExt  and 
AI_Flipf  lop  raises  an  important  issue.  Notice  that  AI_FFExt  includes  a  copy  of  the 
interface  section  of  AI_Flipf  lop.  This  method  of  encoding  a  specification  extension, 
duplicating  the  specification  being  extended,  has  advantages  and  disadvantages  with 
respect  to  the  alternative  approach  of  specification-by-difference.  Figure  3.16  shows 
the  abstract  instance  AI_FFWSet.  AI_FFWSet  specifies  the  same  behavior  as  AI_FFExt 
using  the  specification-by-difference  approach.  AI_FFWSet  uses  AI_Flipf  lop  and  de¬ 
fines  its  own  interface  in  terms  of  the  interface  defined  by  AI_Flipf  lop.  The  statement 
“re-exports  AI_Flipflop”  in  Figure  3.16  includes  all  of  the  interface  section  of 
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specification  AI_FFWSct 
extends  AI__Flipflop 

context 

uses  AI„Flipflop 

interface 

re-exports  AI_Flipflop 

procedure  Sot  (f  :  Flipflop) 

ensures  f  =  TRUE 

end  AI_FFW_Sct 


Fi.min' a.Ki:  Ahstract  Instance  AI_FFWSet 


AI.Flipflop  in  ilic  interface  s('ciion  of  AI_FFWSet.  As  \v('  discuss  in  Clia])t('r  -1. 
re-exports  is  a  lan”na,”,c  nif'clianisni  similar  to  a  static  form  of  inheritance. 

The  ])rimarv  difference  hetween  AI_FFExt  and  AI.FFWSet  is  that  tlu'  behavior  de- 
scritif'd  by  AI.FFWSet  deixmds  uiion  AI.Flipf  lop  wlien'as  the  behavior  de.scribed  by 
AI.FFExt  do('s  not  dejx'iid  on  AI.Flipflop.  Note  that  tlu'  extends  clause  in  both  of 
thesf'  comi)onents  is  only  a  rlniut  docmiH'nt iniz,  an  intended  relationship  ami  does  not 
inflm'nc('  the  Ixduuior  described  by  (’it  lu'r  of  the  compom'nt  s.  An  a  chant  ay,('  of  inch  id- 
im:  the  text  of  tin'  extended  six'cification's  intc'iface  in  the'  component  extending  tlie 
s| lecifica t ion  is  that  the  extc’iidc'd  six’cifictition  is  mort’  coh('si\'e.  A  software  engineer 
attcm|)ting  to  understand  the  Ix’havior  s])ecified  Iw  AI.FFExt  need  oidy  look  at  that 
sinule  compom’nt'’'.  In  orch’r  to  umh’rstand  the  Ix’havior  d(’scrib(’d  by  AI.FFWSet. 
both  AI.FFWSet  and  AI.Flipflop  must  be  examinc’d.  In  tlx’  case  where’  one  sjx'ci- 
fication  extends  mon’  than  oix’  otlx’i  specification,  it  may  Ix’  nc’cc’.ssary  to  examim’ 
sc’veral  spi’cification  com]x)nents  in  orch’r  to  fully  nmlc’rstand  the’  Ix’havior  ch’seribed 
by  a  siimlf'  oxtf'iision  coniiioiuMit . 

An  advnntn^f'  of  \\\r  spf'cififxU ion-hv-difff'i'riK^r  a])])r()acli  is  that  a  s])rcifi('ation  rx- 
TfMision  coniponnnt  is  siiiipl(>r  and  focnsrs  attrntion  on  tln^  sprcificat ion  of  tho  add(xl 
hohavior.  Like*  iniplf'iiif'nt at  ion  units,  lar^f'  (’oni])l('X  s])ncificat  ions  niay  tx'  oasirr  to  iin- 
(hx>tanrl  wlirni  di\  id(‘d  iij)  int o  snialh'r  units.  Also,  with  th(' sp(H’ifi(*ation-l)y~diff(U'(Mi(’o 
aiijiroarh.  \]\vvr  may  Ix’  only  a  sin.ii^h'  ]X)int  of  modification  if  a  specification  compo¬ 
nent  iiefxls  to  Ix'  chane;(xl.  If  tlu'  int('rfac('  of  a  spc'cification  (‘om])onent  with  many 

^  '  fill-  of  conisfh  tlint  tho  inaint ninf'r  uiuhM'staiuls  tlx'  Ix'liavior  of  tho  l)uilt-in  operations 

f"!  Integer  and  Boolean. 
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Figure  3.17:  The  extends  Relationship  Without  and  With  Coupling 


extensions  needs  to  be  changed,  then  all  copies  of  that  interface  embedded  within  ex¬ 
tension  specification  components  probably  need  to  be  changed  as  well.  Of  course,  any 
change  to  a  specification  component  potentially  requires  re-justification  of  extends 
relationships  between  that  component  and  others. 

One  way  to  mitigate  the  problem  of  having  a  single  interface  composed  of  opera¬ 
tions  defined  in  various  components  is  to  use  a  browser  tool  capable  of  displaying  a 
complete  interface  even  if  its  constituent  parts  are  defined  in  several  different  compo¬ 
nents.  Such  a  tool  could  use  the  information  recorded  by  re-exports  clauses  in  order 
to  determine  the  full  extent  of  an  extended  interface.  Meyer  describes  a  tool  with 
similar  capabilities  for  viewing  Eiffel  components  extended  by  inheritance  in  the  “flat- 
short”  form  [Mey94,  p.  29].  In  the  examples  which  follow,  we  use  the  specification- 
by-difference  approach  to  specification  extension.  It  is  important  to  realize,  however, 
that  the  extends  relationship  is  independent  of  the  language  mechanisms,  such  as 
re-exports  or  inheritance,  used  to  encode  a  specification  extension.  As  we  discuss 
in  Chapter  4,  programming  languages  generally  do  not  make  this  distinction  between 
behavioral  and  syntactic  relationships. 

The  top  of  Figure  3.17  shows  the  CCD  depiction  of  the  extends  relationship 
between  AI_FFExt  and  AI_Flipflop.  The  extends  relationship  is  depicted  as  a 
thin  dashed  arrow  from  the  extension  specification  to  the  specification  being  ex¬ 
tended.  In  addition  to  its  extends  relationship  with  AI_Flipflop,  AI_FFWSet  also 
uses  AI_Flipflop.  Since  specification-by-difference  is  the  most  common  way  of  ex¬ 
tending  a  specification,  rather  than  drawing  two  arrows,  we  depict  the  combined 
extends  and  uses  relationships  with  a  thick  dashed  arrow  as  shown  in  the  bottom 
of  Figure  3.17.  The  thick  arrow  indicates  that  AI_FFWSet  depends  on  (is  coupled  to) 
AI_Flipflop. 
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3.5.2  Implementing  Extension  Components 


\\f‘  now  discuss  tliifH'  difh'ifMit  appronclu's  to  (uu'odiiifi,'  an  iin])lfMiHMit atioii  of  an 
al)Straf‘t  cxtc'iisioii  coni])oi!(Mit:  tlic  (Unci,  ('ouph'd.  and  hufficd  ap])iT)ariu\s.  Tlu' 
priinar\-  nioTivation  licr(‘  is  to  dcunonst rat('  another  us('  of  th(^  needs  ndationsliip 
l;i\'c]'f'd  cxtc'iisions.  Tin'  discussion  also  pro\'idcs  more  examples  of  the  implements 
and  uses  relat ionshi))s  and  raisf's  sonu'  interf'stinp;  (h'sion  and  imphunentation  issues. 

I'ieur('  3. IS  shows  CI_FFWSet_l.  a  concn^tc'  instance  that  implements  AI_FFWSet. 
CI_FFV/Set_l  is  a  r/z/w/  im])h'mentation  of  AI_FFWSet.  A  dir(x*t  imphunentation  of  a 
s|)rn“ifi(*ntion  do(‘s  not  (h'pend  on  any  other  im])l(un(Mitations  of  the  specification  heiii.^ 
(‘XtfUKicfl.  I  hus  a  dii'f'ct  ini])l(MnfMit ation  must  imj)l(uii(uit  th('  union  of  the  behavior 
spfH‘ifi(‘d  by  all  ('xtcuision  comj)onents  that  it  iinphunents  including  that  of  tlu^  behav¬ 
ior  bf'iim  ('xt(uuh‘d.  In  this  (*xampl(\  CI_FFWSet_l  must  ]>rovich'  a  r('])r(\sentation  for 
the  t>p(’  Flipflop  and  iniphuiu'ntations  foi*  tlu^  opcu'ations  Toggle  and  Test  as  w(dl 
a^  an  imi)lemr'iit at  ion  for  the  (extension  opfU’ation  Set.  Tlu'  imphunentation  shown 
ill  I  ieur('  3. IS  iisf’s  the  ob\*ious  r('pi’es(Mitation.  a  Boolean  program  type  rej)res(uits 
the  BOOLEAN  math  tyjx'  usc'd  to  model  a  fli])flop.  will  discuss  the  acb’antages  and 
di>aflvant auf'>  of  the'  dire'ct  im])l('m('iit atioii  ap])roach  aftc'r  looking  at  ('xamph's  of  the 
ot her  t W( )  a]>proach(‘s. 

\  imiH'  3.1  D  shows  CI_FFWSet,.2.  anot lu'r  (‘om])on('nt  that  implements  AI.FFWSet. 
CI_FFV/Set_2  is  a  (‘oiipird  im])l('ment atioii  of  AI^FFWSet.  A  couph'd  imphunentation  of 
an  ('xt('nsie)n  has  a  fixe^d  d(^])(uid('ncy  on  a  specifie^  imphuneuitation  of  tlu^  six'dfication 
beinv  exteuuh'd.  I  hat  is.  thf'  (‘Xtfuision  imphuiu'ntation  uses  an  im])l(‘meiitation  of 
the  specification  Ixiiig  ('xteuuhcl.  In  this  cas(\  CI„FFWSet_2  has  a  fixed  de'pendeuicv 
on  CI„Flipf lop„2  (Figure'  3.2)  which  implements  AI_Flipflop. 

I  h('  primary  motivation  for  a  e‘ou])led  imple'inentatie)n  of  an  extension  is  to  allow 
the  exte’iision  imph'me'iit  at  ion  te)  ha\'e'  dire'ct  aecc'ss  te)  the'  data  repre'sentation  of 
a  si)ecific  implenu'nt  at  ion  of  the'  ce)m])on('nt  be'ing  exte'iide'd,  Tdius.  as  with  direct 
im])h'nif'ntat ions,  ne'w  e)])e'rat ions  may  be'  iinple'me'iite'd  in  t('rms  of  a  spe'cifie*  data 
re'i)rf'>e'ntatif)n.  For  example',  the  Set  e)peration  de'fine'd  in  CI_FFWSet_2  uses  the 
Integer  re'pre'se'ntation  e)f  type'  Flipflop  eh'fine'el  in  CI_Flipf lop_2.  As  we  diseaiss  in 
C1iai)te'r  i,  elifle're'iit  i)rograinming  language's  supi)e)rt  a  variety  of  differe'nt  me'elianisms 
that  allow  or  elisallow  eine'  conipone*nt  to  have'  elii’e'eU  aecc'ss  te)  a  t\'pe'  re'])rese'ntatie)n 
eh'fine’d  in  anothe'r  e'e)ni])e)ne'nt .  A  ceuiph'el  iinple'nientatie)n  e)f  an  e'Xte'iision  is  e)nlv 
pos^ibl(‘  whe'ii  the'  ini])le'me'nt at iein  be'ing  ('Xte'iiele'el  is  e'licoeh'el  in  a  way  that  alhnvs 
anothe'r  e*omi)onent  to  elire'ctly  aecc'ss  the  data  re'])re'se'nt ation  e)f  a  type  tliat  it  defiiu's. 

CI_FFV/Set_2  has  elire'ct  aecc'.ss  te)  CI.Flipf lop_2‘s  re'pre'sent atie)n  e)f  Flipflop 
be'cause  CI_FFWSet_2  uses  CI.Flipf lop_2  and  CI.Flipf lop_2  de'fine's  its  re'pre'se'n¬ 
tation  e)f  Flipflop  in  tin'  interface  se'e-tie)n  (as  e)ppe)seel  te)  the  auxiliary  sec'- 
tieui).  I  he-  “re-exports  CI.Flipf lop_2  state'iiu'nt  inclueh's  the'  interface  se'euion 
of  Cl  .FI  ipf  lop„2  in  the  interface  se'ctiein  e)f  CI_FFWSet_2.  This  use  of  re-exports 


implementatioii  CI_FFWSet_l 
implements  AI_FFWSet 

interface 

type  Flipflop  is  represented  by 
state  :  Boolean  :=  False 
end  representation 
exemplar  ff_rep 

correspondence  ff  =  ff_rep. state 

procedure  Toggle  (f  :  Flipflop)  is 

begin 

f . state  : =  not ( f . state) 
end  Toggle 

function  Test  (f  :  Flipflop)  :  Boolean  is 

begin 

return  f . state 
end  Test 

procedure  Set  (f  :  Flipflop)  is 

begin 

f . state  : =  true 

end  Set 

end  CI_FFWSet_l 


Figure  3.18:  CI_FFWSet_l  —  A  Direct  Implementation 


at  the  implementation  level  is  analogous  to  the  use  of  re-exports  by  AI_FFWSet  (Fig¬ 
ure  3.16)  at  the  specification  level.  Whereas  re-exporting  an  abstract  component  may 
be  used  for  achieving  specification-by-difference,  re-exporting  a  concrete  component 
is  useful  for  achieving  implementation-by-difference.  Implementation-by-difference  is 
one  way  to  support  reuse  of  existing  implementation  code  and  is  a  primary  use  of 
inheritance. 

Figure  3.20  shows  CT_FFWSet_3,  a  concrete  template  that  implements  AI_FFWSet. 
That  is,  every  concrete  instance  described  by  instantiating  CT_FFWSet_3  implements 
AI_FFWSet.  CT_FFWSet_3  is  a  layered  implementation  of  AI_FFWSet.  A  layered  im¬ 
plementation  of  an  extension  has  a  deferred  dependency  on  an  implementation  of 
the  specification  being  extended.  That  is,  the  extension  implementation  needs  an 
implementation  of  the  specification  being  extended.  In  this  example,  CT_FFWSet_3 
has  a  deferred  dependency  on  an  implementation  of  AI_Flipf  lop. 
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implementation  CI_FFWSct_2 
imp  1  emen  t  s  hi  _F  F  v;  .Set 

context 

uses  CI_Flipf lop_2 

interface 

re-exports  CI_Flipf lop_2 

procedure  Set  (f  :  Flipflop)  is 

begin 

f  .  state  :  =:  1 

end  Set 

end  CI_FFV.‘Set  2 


I'iuun'  3. If):  CI_FFWSet_2  A  C'()11])1(hI  Iiiiplf'iiif'iitat ion 


Like  n  (‘()iipl(‘fl  iini)l('nirntatioii  of  an  rxlrnsion,  an  insfavtinf inn  of  a  layrnxl  ini- 
pleinentatioii  r('ns(\s  a  spcxafic  iniplcanriitation  of  tlu*  s])(H’ification  being  oxlfnirlecl. 
Howf'Vfnt  since  a  lavf'rf’f!  iin])l(nnent ation  nia\'  Ix'  instantiated  witli  r/////  concrete  in- 
stance  that  implements  tlu'  s])(X'ifi(‘ation  being  ('xtt'iirhHb  it  only  has  access  to  th(' 
interface  chdiinHl  by  th('  specification  it  needs.  Thus  a  layered  iini)l('nientation  does 
net  ha\'e  dirc’ct  accc'ss  to  the'  concrc'tt'  r('pr("S(Mitation  of  any  types  (h'fined  in  tin' 
conipcnent  bfhng  extcnidf'd.  ()i)erat  ions  chdiiu'd  in  a  layertxl  ini])lenientation  of  an  ex- 
ten^inii  must  Ix'  (Micodcxl  in  tc'rins  of  ‘'layt'rt'd"  on  to])  of  ojx'ratioiis  i)rovid('d  bv 
the  coni])onent  Ixxng  ('xtf'ndfxl.  Xot('  that  wn  have  alr('ad>’  set'ii  exani])l(\s  of  la\'('ring 
nsfu!  to  ini]>h’nient  one  abstraction  in  terms  of  another:  CT_Threeway_l  (Figure  3.8) 
and  CT_Stack_l  (Figiirt'  3.11). 

for  CT_FFV/Set_3,  shown  in  h'igun'  3.20.  tlx'  interface  st'ction  mnst  bc'  (h'fined 
in  terms  of  tlx'  abstract  int('rfa(‘('  ])ro\’id('d  by  AI-Flipflop.  Thus  tlx'  o])eration 
Set  i>  imi)h'nx'nt('d  in  terms  of  tlx'  ojx'rations  Toggle  and  Test,  as  s]x'(‘ifi('d  bv 
AI.Flipflop.  ratlx'i'than  in  tc'rms  of  a  s|)ecific  data  re])r('S('ntation.  Tlx'  “re-exports 
CI^Flipflop*  statf'ment  inchxh's  tlx'  interface  st'ction  of  tlx'  coix'rett'  instaix't' 
usr'rl  to  instantiate'  CT_FFV/Set..3  as  i)art  of  the  intt'rfact'  ch'scrilx'd  by  an  ijisfnjffi- 
nfion  of  CT^FFV/Set_3.  Thus  tlx'  concrt'te'  instaixn'  dt'scrilx'd  by  an  instantiation  of 
CT„FFV/Set_3  pro\-id(*s  ('verything  in  tlx'  intt'rface  of  tlx'  coix'retc'  instance  whicii  serves 
at  the  actual  paranx'ter  for  CI_Flipflop,  ])lns  an  imph'nx'iit ation  of  tlx'  operation 
Set.  Sinc('  a  concrete'  instance'  that  implements  AI.Flipflop  may  imi)le'ment  more' 
bf'havior  than  that  s])f‘cifie'd  by  AI.Flipflop.  an  instantiation  (^f  CT_FFWSet_3  may 


iitiplementation  CT_FFWSet_3 
implements  AI_FFWSet 

context 

uses  AI_Flipflop 

needs  CI_Flipflop  implementing  AI_Flipflop 

interface 

re-exports  CI_Flipflop 

procedure  Set  (f  :  Flipflop)  is 

begin 

if  not (Test (f))  then 
Toggle (f ) 

end  if 
end  Set 

end  CT_FFWSet_3 


Figure  3.20:  CT_FFWSet_3  —  A  Layered  Implementation 


correspondingly  implement  more  behavior  than  that  specified  by  AI_FFWSet.  Re¬ 
gardless  of  how  CT_FFWSet_3  is  instantiated,  however,  its  contents  may  only  refer  to 
types  and  operations  as  specified  in  AI_Flipf  lop  (and,  of  course,  built-in  types  and 
operations). 

Figure  3.21  shows  the  code  for  three  instantiations  demonstrating  how  a  lay¬ 
ered  implementation  of  an  extension  may  be  instantiated  and  the  resulting  con¬ 
crete  instance  further  extended.  The  first  instantiation  defines  the  concrete  instance 
CI_FFBase  which  describes  the  behavior  specified  by  AI_Flipf lop  (the  type  Flipflop 
and  operations  Toggle  and  Test)  as  implemented  by  Cl_Flipf  lop_2.  The  second 
instantiation  defines  the  concrete  instance  CI_FFWSet  which  describes  the  behavior 
specified  by  Al_FFWSet  as  implemented  by  CT_FFWSet_3  instantiated  with  Cl_FFBase. 
Thus,  Cl_FFWSet  provides  implementations  of  Toggle  and  Test  as  described  by 
Cl_Flipf  lop_2  and  an  implementation  of  Set  realized  by  calls  to  those  implementa¬ 
tions  of  Toggle  and  Test. 

The  third  instantiation  defines  the  concrete  instance  CI_FFWSetReset  using  the 
specification  Al_FFWReset  and  the  implementation  CT_FFWReset_3.  Al_FFWReset  ex¬ 
tends  Al_Flipf  lop  with  the  operation  Reset  in  the  same  way  as  Al_FFWSet  does  with 
Set.  CT_FFWReset_3  implements  Al_FFWReset  in  the  same  manner  Cl_FFWSet_l  im¬ 
plements  AI_FFWSet.  (The  code  for  Al_FFWReset  and  CT_FFWReset_3  is  not  shown.) 
CI_FFWSetReset  describes  the  behavior  specified  by  the  union  of  Al_FFWSet  and 
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implementation  CI_FFBaHc 
implements  AI_Flipflop 
by  CI_Flipf lop„2 

implementation  CI__FFWSct 
implements  AJ_FFVJSot 
by  CT_FFW5^ot:_3  with 

(CI_Flipflop  =>  CI_FFBaso) 

implementation  CI_FFWSct:Rc5Ct 

implements  AT_FF‘WSct ,  AI_FFV:Rcsct 
by  CT_FFWRcsct__3  with 

(CI_Flipflop  =>  CI_FFWSct) 


I  .^.21:  liistniitiation  of  Lay(M*r(i  Ext('nsioii  Iinj)l('nu'nt atioiis 


AI_FF'i'/Reset  as  ini])lf'in(aitf‘(l  hy  CT_FFWReset_3  instantiatcvl  witli  CI_FFWSet.  thv  vr- 
suit  of  tli('  Sf'coiid  inst;niti;iti()ii.  Tims.  CI_FFWSetReset  i)n)vi(lcs  the  concn'tc  ryjx' 
Flipflop  and  operations  Toggle,  Test.  Set.  and  Reset. 

Note  that  the  dirc'ct  and  coitijlcd  inii)l('ni('nt ations  of  AI.FFWSet  could  Ix'  instan- 
tiaterl  in  imich  the  same  way  as  the  first  instantiation  shown  in  Figure  3.21.  In  both 
ea'-^es  '  implenients  would  Ix'  lollow('d  with  "AI-FFWSet  .  For  tlx'  direct  iinphunen- 
tation.  "by  \wiuld  Ix'  followed  by  "CI_FFWSet_l " .  For  the  couph'd  iinpleinentation. 
"by"  would  Ix'  follow('d  by  "CI_FFWSet-2" . 

l  iuure  3.22  is  a  C'C'I)  d('])icting  the  thn'e  different  iinphuiientations  of  AI.FFWSet 
as  wi'll  two  ini])lenu'nt  at  ions  of  AI.Flipflop  and  the  relationshi])S  among  these  com¬ 
ponents.  CI_FFVi'Set_l  h;is  no  dependencies  on  other  comjxxK'nts  (exc('j)t  for  tin' 
built-in  coinjionent  CI_Boolean_l  which  we  do  not  show).  1  hits  tnoflifications  to  other 
comixments  cannot  affect  the  behavior  descrilx'd  by  CI^FFWSet_l.  If  AI_FFWSet  or 
AI.Flipflop  were  modified,  tlxui  tin'  correctness  of  th('  claim  that  CI.FFWSet.l  im¬ 
plements  AI.FFWSet  (and  im])Iicitly  AI.Flipflop)  might  change,  but  not  tiu'  Ix'hav- 
ior  implemented  by  CI.FFWSet.l.  The  uses  ndat  ionship  shown  betweem  CI_FFWSet_2 
aixl  CI_Flipflop.2  (h>i)icts  the  fixed  dependency  of  CI.FFWSet.2  on  CI.Flipf lop.2. 
This  indicatf's  that  a  modification  to  CI.Flipf lop_2  may  alter  tlx'  Ix'havior  de¬ 
scribed  by  CI_FFWSet_2,  'Fhe  needs  n-hitionshi])  shown  Ix'tween  CT.FFWSet.S  and 
AI.Flipflop  (lejucts  tlx’  defeured  deixuidency  of  CT.FFWSet.S  on  AI.Flipflop.  That 
is.  CT.FFWSet.3  neerls  an  imph'iiu'ntat ion  of  AI.Flipflop.  A  change  to  tlx'  specifi¬ 
cation  AI.Flipflop  could  aflect  the  Ix'htivior  dt'seribed  by  CT.Flipf lop.3.  However, 
changes  to  an\-  implementations  of  AI.Flipflop  cannot  alt('r  the  Ix'havior  de.scrilx'd 
by  CT.FFWSet.3. 


Figure  3.22;  Three  Ways  To  Implement  An  Extension 


We  now  address  the  relative  advantages  and  disadvantages  of  each  of  the  three 
approaches  to  implementing  an  extension.  The  direct  approach,  exemplified  by 
CI_FFWSet_l  in  Figure  3.18,  is  generally  the  least  attractive  of  the  three  alternatives 
since  it  requires  implementing  the  component  being  extended,  in  addition  to  the  ex¬ 
tension,  from  scratch.  Both  the  coupled  and  layered  approaches  have  the  advantage 
of  reusing  existing  implementation  code.  The  principal  advantage  of  the  direct  ap¬ 
proach  is  that  the  code  implementing  the  extension  operations  can  have  direct  access 
to  data  representations  which  cannot  be  accessed  directly  using  the  layered  approach 
and  which  may  not  be  accessible  at  all  to  other  components  (in  which  case  the  coupled 
approach  cannot  be  used).  With  direct  access  to  the  representation,  it  may  be  pos¬ 
sible  to  implement  some  extension  operations  much  more  efficiently  than  is  possible 
with  layering.  While  there  is  unlikely  to  be  a  performance  advantage  using  a  direct 
implementation  in  the  case  of  CI_FFWSet_l,  we  present  an  example  in  Section  3.5.3 
where  the  direct  approach  does  provide  a  significant  performance  improvement  over 
the  layered  approach. 

The  coupled  approach,  exemplified  by  CI_FFWSet_2  in  Figure  3.19,  offers  the  prin¬ 
cipal  advantage  of  the  direct  approach,  direct  access  of  extension  operations  to  data 
representations,  and  one  of  the  main  advantages  of  the  layered  approach,  reuse  of 
existing  implementation  code.  Thus  in  some  cases,  a  coupled  implementation  may  be 
significantly  more  efficient  than  a  layered  alternative  and  less  costly  to  develop  than  a 
direct  implementation.  A  disadvantage  of  the  coupled  approach  is  that  it  typically  re¬ 
quires  “privileged”  access  to  an  existing  implementation  component  in  order  to  break 
encapsulation  and  gain  direct  access  to  data  representations  of  types  defined  within 
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tlif'  inipl(^inf'iiT at  ion  Ix'ino  rxtf'iulrd.  Wr  discuss  this  issue  more  in  Chaptcu*  i.  In  a 
softvrarf'  coin])oiH'nts  industry  in  wliieli  iinphunentation  ('oin])onents  are  distributed 
in  ‘'l)lack  box  ob jf'ct-eodf'  format,  (‘ou])l('d  imi)l('mentations  of  ('xtfuisions  are  not  an 
oi>tion  except  for  ortz;ani/at ions  wliich  liav('  tlu'  source'  code'  e)f  the'  imple'mentatieui 
bf'ine  e'xte'iiele'fl.  1*  inally.  just ifvin.u;  that  a  ce)U])Ie'el  im])lementation  ce)rre'ctly  imple¬ 
ments  an  f'xte'nsion  spe'e‘ifie‘atie)n  may  re'eiuire'  signifie*ant  effort  \vliie*li  is  not  reepiire'd 
whe'ii  tli('  layere'd  a])])roae‘h  is  use'el.  Lelwarels  diseaisse's  I  lie'  subt  le't  ie's  of  this  issue  in 
te'rin^  e)f  wliat  lie'  e*alls  *’re'i)r('se'nt at ie)n  inherit ane^e" .  a  fe)rm  e)f  extensie)!)  by  ce)Uj)le'd 
imi)le'nie'ntatie)n  fljhvnOb 

1  he'  laye're'el  a])])roae*h,  exeinplifie'el  by  CT„FFWSet_3  in  Figure'  3.20.  e)ffe'rs  significant 
aelvantage's  o\-e'r  the'  elii'e'eU  and  e*e)upl(*el  a])pre)ache's  with  re'latively  mine)r  drawbac'ks. 
As  with  the'  e*ou])le'd  ap])roae‘h,  the'  layere'el  a])])re)ae*h  re'uses  the  e‘e)ele'  e)f  an  existing 
imple'iiif'nt  at  ion  e)f  the'  spe'e*ifi(‘at  ie)n  be'ing  exteneled.  Ileiwe've'r.  the'  layere'd  a])])re)ach 
eloe‘>  ne)t  re'e|uire‘  privile'ge'el  acea'ss  te)  the'  im])le'nie'ntat iein  be'ing  e'xtenele'd  since  it  views 
the'  iniple'inf'Ut at ie)n  in  te'i’iiis  eif  an  abstraei  inte'rfae*e'.  A  nia  je)i'  bene'fit  e)f  the'  la\'e'i'e'el 
e'Xte'n^ion  imi)le'ment  at  ion  is  that  it  e*an  be'  use'el  te)  extend  ani/  im])le'mentatie)n  e)f  the' 
s])f'e-ifie‘at ion  be'ing  e'xtenele'eh  ne)t  just  a  single'  im])le'ment at ie)n  as  is  the'  e*ase  with  the 
e‘e)U])le'd  api)roae-h.  J  his  make's  it  possible'  te)  “chain"  te)ge'the'r  multiple'  extensie)ns 
a^  shown  in  Figure'  3.21.  Laye'ring  also  insulates  an  e'xtensie)n  fre)m  me)elifie‘ations  to 
imi)le'nie'ntations  e)f  the*  s])e'e*ifie“atie)n  be'ing  e'xtenele'eh 

I  he*  exte'iision  im])le'me'nt at ie)n  task  shoulel  be  ce)ne‘e'pt ually  e'asier  with  the*  lav- 
e're'd  approae*h  sine’e*  a  software*  e'ligine'er  iinple'iue'iit ing  layere'el  exte'nsie)n  e)])eratie)ns 
e)nly  needs  te)  unele'rst atul  the*  be'havie)ral  spe'eafie'at ie)n  e)f  the*  imple'mentatie)n  be'ing 
e'xte'iide'd  and  ne)t  any  e)f  its  ini])le'me'nt at ie)n  ele'tails.  sue'h  as  data  repre'se'utations.  An 
e'liipirie’al  stiirly  by  Zwebe'ii,  et .  ah.  pre)viele's  e'\‘ide'ne‘e'  that  the*  laye'ring  ai)]u*e)ae*h  e-an 
h'ad  te)  highe'r  pre)gramme'r  pre)due‘t ivity  anel  lowe'r  de'fe'e’t  rate's  [ZFAMIOr)].  As  men- 
tioiK'd  above*,  justifying  that  an  imple'mentatie)n  e'xte'nsie)n  is  e*e)rre'e’t  with  re'spee’t  te) 
the*  s])e'cifie‘at ion  it  ini])le'nu'nts  is  typie-ally  e'asie'r  foi*  laye're'el  im])!e'mentations  than  fe)r 
e'e)upl('el  im])le‘ine'nt  at  ions.  I  he*  rease)n  fe)i*  this  is  that  e)perations  impleme'iite'el  bv  lav- 
e'rinu  e-annot  violate*  re'])re'se'ntatie)n  invariants  e)f  the*  im])le'mentatie)n  be'ing  e'xte'iide'el 
a^  long  as  the*  unele'rlying  e)pe'rations  are*  ce)rreelly  im])le'mente'd  and  e’alle'el  e)nly  whe'ii 
the'ir  ])i'e’e-one!it  ions  are*  satisfie'd. 

A'^  ne)tf'd  above*,  the*  ])riniarv  elisaflvantage*  e)f  laye'red  ini])le'nientat ie)ns  is  that 
ihe'y  ma\‘  be*  h'ss  e'ffie‘ie*nt  than  e'e)niparable*  elire'e’t  or  ce)uple'el  implemeiitatie)ns.  The* 
inefficie’iicy  arise's  fre)ni  the*  aelelit ie)nal  e)])eratie)n  e*alling  e)ve'rhe'ael  re'([uireel  te)  inve)ke 
e )])e'rat ions  e)f  the*  imi)le'me'ntatie)n  be'ing  e'Xte'iiele'd  and,  in  se)me'  (‘ases,  arises  fre)m  a 
signifie  ant ly  ine-re'ase'el  alge)rit limie*  e’e)m])Ie'xity  re'sulting  freim  the  limitatie)ns  e)f  in- 
eliie’ct  elata  niani])ulat ie)n.  hor  e'xample*.  the*  imple'ine'ntat ions  e)f  Set  ele'seuibe'd  by 
CI_FFWSet_l  (Figure*  3.1S)  and  CI_FFWSet_2  (Figure  3.19)  are  like'ly  te)  be  me)re  effi- 
e-ie'iit  than  the*  laye're'el  ini])le'ment atie)n  eif  Set  ele'se*ribeel  by  CI.FFWSet  (Figure  3.21), 
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but  only  by  a  constant  factor.  In  some  cases,  the  additional  operation  calling  over¬ 
head  resulting  from  layering  may  be  reduced  by  using  optimization  techniques  such 
as  in-lining  of  operations.  Another  disadvantage  inherent  to  the  layering  approach  is 
that  clients  of  layered  extensions  must  instantiate  the  concrete  template  defining  a 
layered  implementation  in  order  to  generate  a  useful  concrete  instance.  This  problem 
may  be  mitigated  by  “pre-instantiating”  components  using  a  technique  called  partial 
instantiation.  We  discuss  partial  instantiation  in  Chapter  5. 

The  layered  approach  to  implementing  extension  specifications  is  the  primary 
approach  used  by  the  RESOLVE  discipline  [SW94,  p.  41].  In  Section  5.6  we  present 
examples  of  how  layered  extensions  are  encoded  in  RESOLVE/Ada95. 

3.5.3  Extension  Of  Template  Components 

On  page  64  we  listed  three  distinct  relationships  which  apply  to  the  overloaded 
term  extends.  The  extends  relationship  between  two  abstract  instances  was  exem¬ 
plified  by  the  relationship  AI_FFWSet  extends  AI_Flipf  lop.  The  second  relationship, 
an  abstract  template  that  extends  an  abstract  instance,  could  be  used  to  express  a 
deferred  dependency  on  a  component  used  by  an  extension,  but  not  by  the  abstract 
instance  that  the  extension  extends.  We  include  this  second  definition  of  extends 
for  completeness  and  do  not  provide  an  example.  In  this  section  we  discuss  the  third 
extends  relationship  between  two  abstract  templates. 

Figure  3.23  shows  the  abstract  template  AT_SWRev  that  extends  AT_Stack  (shown 
in  Figure  3.10)  in  accordance  with  the  third,  template-to-template,  definition  of  ex¬ 
tends.  Since  AT_Stack  is  an  abstract  template,  AT_SWRev  must  also  be  an  abstract 
template.  This  is  the  only  way  that  all  of  the  interface  defined  by  AT_Stack  can 
be  included  in  the  interface  defined  by  AT_SWRev  as  necessary  for  justifying  the 
extends  relationship.  Like  AT_Stack,  AT_SWRev  needs  a  concrete  instance  that 
implements  Al_AnyType  to  provide  a  definition  of  the  type  of  element  contained 
within  the  stack.  The  type  corresponding  to  AnyType  in  the  actual  parameter  bound 
to  Cl-StackWRltemType^^  determines  the  type  of  elements  contained  in  the  stack. 
AT_SWRev  uses  AT_Stack  in  order  to  define  its  interface  in  terms  of  the  interface 
specified  by  AT_Stack.  However,  since  AT_Stack  is  an  abstract  template,  its  interface 
section  cannot  be  re-exported  directly  as  was  the  case  with  Al_FFWSet  re-exporting 
the  interface  of  Al_Flipflop  (Figure  3.16). 

Since  AT_Stack  is  a  template,  the  meaning  of  its  interface  section  depends  on 
the  binding  of  its  formal  parameter  Cl_StackltemType.  Thus,  in  order  for  the  re¬ 
exported  interface  of  AT_Stack  to  have  any  meaning,  Cl_StackltemType  must  be 
bound  to  some  concrete  instance.  Furthermore,  for  an  instantiation  of  AT.SWRev 

^^Note  that  any  formal  parameter  name  would  do  where  we  use  CI_StackWRItemType.  Normally, 
we  would  use  the  same  formal  parameter  name  here  as  in  AT_Stack.  However,  in  this  example  we 
use  different  formal  parameter  names  in  order  to  make  the  code  easier  to  understand. 
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specification  AT^SWRov 
extends  AT__Sl.ack 

context 

uses  AT_Stack 
uses  A I  _Ar.y  Ty  pc 

needs  CI_St_ackV;RI tcmTypc  implementing  AI_AnyTypc 

interface 

re-exports  AT_St,ack  with 

(CI^SLackltcrnTypc  =>  CI_St:ackWRT tcmTypc ) 

procedure  Reverse  (s  :  Stack) 
ensures  s  =  REVERSE  (f?s) 


I  i,L!;iirr  3.23:  An  Kxtf'iision  of  An  Ahsti'act  leinplntc' 


to  extend  an  instantiation  of  AT^Stack.  both  sjx'cificat ions  clt'arly  need  to  six^eify 
stfifk^  with  th('  sanu'  ty])o  of  ('hainnits.  Tlu'  re-exports  claiist'  in  AT_SWRev  addresses 
Ixjtli  of  thf'sf’  issiu's  by  df'seribinn-  tlu'  r('-('X])ort(Hl  intc'rfaee  as  AT_Stack  instantiated 
with  CI.StackV/RItemType  serving  as  tin'  aetiial  i)aranieter  for  CI.StackItemType. 
I  hat  is.  tin'  int('rfaef'  (h'serilxx!  by  an  instaiie(’  of  AT-SWRev  inelud(\s  the'  int('rfac‘(' 
flf'srribf'd  tw  an  instanef'  of  AT.Stack  instantiate'd  witli  tiu'  same  eonerete  instance' 
use'd  to  instantiate'  AT_SWRev. 

Ib'eall  that  the'  ele'finition  e)f  extends  be'twe'e'ii  two  abstract  template's  re'eiiiire's 
that  for  r/////  inst ant iatie)!)  of  AT.Stack,  say  Al\,  the’re'  ('xists  sodk^  instantiation  of 
AT_SV/Rev,  sa\*  AIj,  such  that  Afj  extends  AI]  (by  the'  de'finitie)n  e)f  extends  be'- 
twee'ii  two  abstraei  inst ane-e's).  We*  claim  that  AT_.SWRev  extends  AT.Stack  for  the* 
following  rc’ason.  Assume*  that  AT.Stack  is  instantiate'el  with  the*  cone*ret('  instane*e' 
C  I  sf'r\-ing  as  the*  aegiial  paranu'te'r  ce)rre's])oneling  te)  AT.Stack's  formal  paranu'ter 
Cl  _StackI  temType.  I  Ih'd  any  inst  ant  iat  ie)n  e)f  AT.SWRev  with  Cl  as  the*  aegiial  param¬ 
eter  e'orre'S])e)neling  to  AT.SWRev  s  fe)rmal  ])aranie'ter  CI.StackWRItemType  extends 
the*  instantiation  e>f  AT.Stack  with  C7  (by  tlie*  d('finitie)n  of  extends  betwe'e'n  two  ab- 
strae't  inst aiK’f's).  T  liat  is,  if  AT.Stack  anel  AT.SWRev  are*  instantiate'el  with  the  same 
cone-re'te*  instane-e*,  the'ii  the*  inst  ant  iat  ie)n  of  AT.SWRev  extends  tlie*  instantiation  of 
AT.Stack.  1  his  im])lie's  that  any  cone're'te*  instane’e*  that  implements  an  instantiatie)n 
e)f  AT.SWRev  aKo  implements  the*  e'e)rr('spe)neling  instantiation  of  AT.Stack.  We  will 
look  at  an  ('xample*  e)f  he)w  tlie'se  com])e)ne'nts  may  be*  instantiate'el  afte'r  le)e)king  at  a 
ce)mi)onf'nt  that  implements  AT.SWRev. 
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implementation  CT_SWRev_l 
imp 1 ement  s  AT_S WRe v 

context 

uses  AI_AnyType 
uses  AT_Stack 
uses  AT_Queue 

needs  CI_StackWRItemType  implementing  AI_AnyType 
needs  CI_Stack  implementing  AT_Stack  with 

(CI_StackItemType  =>  CI_StackWRItemType) 
needs  CI_Queue  implementing  AT_Queue  with 

(CI_QueueItemType  =>  CI_StackWRItemType) 


interface 

re-exports  CI_Stack 

procedure  Reverse  (s  :  Stack) 
q  :  Queue 
X  :  Any Type 

begin 

for  i  in  1  ..  Length (s)  loop 
Pop(s,  x) 

Enqueue (q,  x) 

end  loop 

for  i  in  1  ..  Length (q)  loop 
Dequeue (q,  x) 

Push(s,  x) 
end  loop 

end  Reverse 

end  CT_SWRev_l 


Figure  3.24:  A  Layered  Implementation  of  AT_SWRev 


Figure  3.24  shows  the  concrete  template  CT_SWRev_l,  which  is  a  layered  imple¬ 
mentation  of  AT_SWRev.  This  implementation  reverses  a  stack  by  popping  each 
element  off  the  stack  and  enqueueing  it  into  a  (first-in-first-out)  queue  followed 
by  dequeueing  each  element  from  the  queue  and  pushing  it  back  onto  the  stack. 
CT.SWRev.l  uses  AI_AnyType,  AI_Stack,  AI^Queue,  and  implicitly  CI_Integer_l  and 
CI_Boolean_l.  CT_SWRev_l  needs  an  implementation  of  AI_AnyType,  and  implemen¬ 
tations  of  AT_Stack  and  AT.Queue,  both  instantiated  with  the  same  concrete  instance 
serving  as  the  implementation  of  AI_AnyType. 
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1' 3.2.“):  Hcluivioral  Hc'lntioiisliips  of  CT_SWRev„l 


Itooi  a  (■oiii])oiif'iit  niaiiit(Mian{*('  prrsjx'ctivc'.  wv  lar^rly  can  ignon'  CT.SWRev.Ts 
(l('pfMHlciH‘ics  on  AI^AnyType,  CI„Boolean„l,  and  CI_Integer_l^  ’  since'  tlu'se'  coin- 
pont'iiTs  are'  fixe'd  hy  tlu'  language'  and  will  not  change'.  Jims  CT_SWRev_l's  needs 
re'laTi()nsliij)s  with  AT_Stack  and  AT_Queue  suniiiiari/('  the'  e*ritical  de'sign  de'ix'iide'n- 
f( )!'  t his  c( )inpone'nt . 

l  igure'  3.2-)  is  a  C  C  that  shows  CT_SWRev_l  and  the'  coinpoiu'nt  rclationshi])S 
pe'rtine'iit  to  iineh'rst aneling  tlie'  he'havior  of  and  use'  e)f  CT_SWRev_l.  Tlie'  tliick  arn)ws 
(needs  anrl  extends  with  uses)  ele'])ie*t  e*e)upling  e)r  de'i)e'nele'ne*y  relationships.  The' 
thin  arrow  (implements)  eh'pieUs  a  piire'ly  l)e'liavie)ral  re'lationship.  I'lie'  iinple'ine'nta- 
tion  he'havior  e'nce)de‘d  hy  CT_SWRev_l  de'pe'iids  on  the  he'havie)!*  spe'eafie'd  hy  AT^Stack. 
AT_Queiie.  anel  AI_AnyType.  While'  AT„SWRev  may  l)e'  iise'd  as  a  spe'cifie*atie)n  of  the' 
he'havior  of  CT_SWRev_l.  the'  he'havie)r  ini])le'inente'd  hy  CT„SWRev_l  in  lU)  way  depends 
njeni  AT_Sl*/Rev.  1  Inis  e)nly  change's  te)  AT_Stack  and  AT_Queue  ce)ulel  alte'r  the'  he'lun'- 
ie)]'  (h'serihe'd  hy  CT_SV/Rev_l.  Xe)te'  that  ITgui'e'  3.23  de)e's  ne)t  e'lie'oeh'  the'  re'Cjuire'nient 
that  CT_SV;Rev.l,  AT_Stack,  and  AT.Queue  must  all  he'  instantiate'el  witli  the  same  im- 
ph'me'iitatie)!)  e)f  AI.AnyType.  The'  ce)ni])e)nent  instantiatie)n  diagrams  (CdD's)  shown 
in  C‘ha])te'r  3  conve'v  more'  ch'taih'el  iidormation  sueT  as  this. 

l  igure'  3.23  shows  the'  ce)e!e'  ele'se*rihing  an  inst antiatie)n  of  CT_SWRev_l.  The'  cem- 
eaeUf'  instance'  CI_.FFSWRev  ele'se’ril)e's  an  imple'mentat ie)n  e)f  a  stack  of  flip-fle)|)s  pre)- 
vidine  a  stack  Reverse  e)pe'rat ie)n.  CI.FFSWRev  implements  AT.SWRev  instanti- 
ate'd  with  CI_Flipf lop_3.  Ih'call  that  the'  ce)de'  eh'serihing  the  ce)ncre'te'  instances 

Ci„Si'.Rev>  fixf'rl  clcj)f’iKl('nrv  on  CI_Integer_l  coulcl  Ix'  significant  to  a  inaintaiiu'r  since  tlu' 
laTfcr  flffiiif'-  an  iniplcmcnt at ioii-flcpciuh'nt  inaxinnnn  Integer  valiu'.  Howe^ver.  an  “iinhonndccr' 
."tar'l:  a-  -.pccafif'd  i)>'  AT_Stack  would  not  Ix'  aj)propriat('  for  apj)lications  in  which  tlif'  stack's  le'iigth 
{‘oiild  ]x iTfiitially  grow  larger  than  tlx'  inaxininin  Integer  valiH'. 


implementation  CI_FFSWRev 
implements  AT_SWRev  with 
(CI_StackWRItemType  => 
by  CT_SWRev_l  with 

(CI_StackWRItemType  => 
CI_Stack  => 
CI_List  => 


CI_Flipf lop_3 ) 

CI_Flipflop_3, 
CI_Flipf lop_Stack, 
CI_FLipf lop_List) 


Figure  3.26:  Instantiation  of  CT_SWRev_l 


CI_Flipflop_Stack  and  CI_Flipf lop_List  was  shown  in  Figure  3.13.  The  imple¬ 
ments  relationship  between  CI_FFSWRev  and  AT_SWRev  can  be  justified  here  only 
because  all  of  the  template  components  involved  have  been  instantiated  with  the 
same  concrete  instance,  CI_Flipf  lop_3,  as  the  stack  element  type. 

Since  CT_SWRev_l  is  a  layered  implementation  of  AT_SWRev,  it  may  be  used  to 
extend  any  component  that  implements  AT.Stack  but  does  not  depend  on  any 
other  implementation  components.  Despite  these  advantages,  the  layered  approach 
precludes  an  efficient  constant-time  Reverse  operation  in  this  case.  The  Reverse 
operation  encoded  in  AT_SWRev  executes  in  linear  time  with  respect  to  the  length  of 
the  stack  being  reversed.  A  stack  Reverse  operation  layered  on  top  of  the  interface 
provided  by  AT.Stack  can  do  no  better  than  linear  time.  A  client  application  that 
needs  to  reverse  stacks  frequentlj’^,  might  justify  creating  a  direct  implementation  of 
AT_SWRev  with  a  Reverse  operation  that  runs  in  constant  time. 

Figure  3.27  shows  the  concrete  template  CT_SWRev_2  which  we  claim  implements 
AT_SWRev.  This  is  a  direct  implementation  of  AT_SWRev  since  it  defines  its  own 
stack  representation  and  implementations  for  Push,  Pop,  and  Length  in  addition 
to  Reverse.  CT_SWRev_2  needs  an  implementation  of  AT_Two_Way_List,  a  specifica¬ 
tion  similar  to  AT_One_Way_List  except  that  it  includes  a  Retreat  which,  along  with 
Advance,  supports  traversal  of  the  list  in  both  directions.  A  two-way  list  has  the 
same  model  as  a  one-way  list,  a  pair  of  strings.  The  representation  of  type  Stack  has 
two  components;  a  (two-way)  List  labeled  holder  and  a  Boolean  labeled  left-top. 
left-top  is  used  to  keep  track  of  which  end  of  the  list  represent  the  top  of  the  stack. 
When  the  value  of  left-top  is  True,  the  portion  of  the  list  corresponding  to  the  right 
string  represents  the  stack  with  the  stack  top  being  the  left-most  element  in  the  right 
string.  When  the  value  of  left-top  is  False,  the  portion  of  the  list  corresponding  to 
the  left  string  represents  the  stack  with  the  stack  top  being  the  right-most  element 
in  the  left  string.  Using  this  representation,  the  Reverse  operation  is  implemented 
by  simply  changing  which  end  of  the  list  currently  represents  the  top  of  the  stack. 

Achieving  a  constant  time  reverse  operation  does  require  slightly  more  complex 
and  slower  implementations  of  Push,  Pop,  and  Length  since  each  of  these  operations 
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implementation  CT__SWRov__2 
implements  AT_SV:Rov 

context 

uses  A I „ Any Ty p c 
uses  A7_Tv;o_v;ay_List 

needs  CI_StackI tcrr^Typc  implementing  AI„AnyTypo 
needs  CI_List  implementing  AT_Tv/o_Way_Lis t  with 
{ C I _L i s 1 1 L cn'iTyp c  =  >  Cl _Any Ty p o ) 

interface 

type  Stack  is  represented  by 

holder  :  List 

lcft_top  :  Boolean  :=  True 

end  representation 
exemplar  s__rep 

convention  if  s_rep . lef t_top  then 

s_rop. holder . loft  =  EMPTY_STRING 

else 

s_rop. holder .right  =  EMPTY_STRING 

correspondence  if  s_rcp .  lef  t__top  then 

s  =  REVERSE (s„rcp. holder. right) 

else 

s  =  s_rep . holder . lef t 

procedure  Push  (s  :  Stack,  x  :  AnyTypo) 

begin 

Add_Right (s .holder,  x) 

if  not ( s . Icf t_top)  then  Advance ( s . holder )  end  if 
end  Push 

procedure  Pop  (s  :  Stack,  x  :  AnyType) 

begin 

if  not  ( s  .  lef  t_top)  then  Reti'cat  ( s  ,  holder )  end  if 
Rerr.ove_Ri  ght  ( s  .  holder  ,  x) 

end  Pop 

function  Length  (s  :  Stack)  :  Integer 

begin 

if  s.lcft_top  then  return  (Right_Length (s . holder 
else  return  (Lef t_Lcngth (s . holder ) )  end  if 
end  Length 

procedure  Reverse  (s  :  Stack) 

begin 

if  s.lcft_top  then  Move„To_Finish ( s . holder ) 
else  Kove_To_Start ( s . holder )  end  if 
s.lcft_top  ;=  not (s . lef t_top) 
end  Reverse 
end  C7_S/rRcv  2 


1' 3.27:  A  Din'd  IiiiphTiiontatioii  of  AT_SWRev 
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must  test  for  which  end  of  the  list  represents  the  top  of  the  stack.  An  implemen¬ 
tation  of  a  two-way  list  also  is  likely  to  require  more  memory  than  a  one-way  list 
implementation.  Nevertheless,  if  a  fast  reverse  operation  is  important  to  the  client 
application,  then  the  direct  implementation  approach  is  justified  in  this  case.  Note 
that  a  coupled  implementation  is  unlikely  to  be  of  use  in  this  situation  since  the 
implementations  Push,  Pop,  and  Length,  as  well  as  the  data  representation,  must  be 
specifically  designed  for  a  constant-time  reverse  operation. 


3.6  Behavioral  Substitutability  of  Components 

With  the  relationships  we  have  defined,  it  is  now  very  simple  to  characterize  when 
one  software  component  is  substitutable  for  another.  Since  an  integrated  system 
consists  of  all  concrete  instances  (e.g..  Figure  3.14(a)),  component-level  system  main¬ 
tenance  involves  replacing  one  concrete  instance  with  another.  However,  a  maintainer 
cannot  replace  one  concrete  instance  with  another  without  knowing  the  behavioral  re¬ 
quirements  the  system  has  for  the  component  being  replaced.  Two  different  concrete 
instances  may  be  substitutable  with  respect  to  one  specification,  but  not  with  respect 
to  another.  Therefore,  the  substitutability  relationship  is  a  ternary  relationship  in¬ 
volving  two  concrete  instances  and  an  abstract  instance  identifying  the  minimum 
behavioral  requirements  of  the  system  for  both  concrete  components. 

For  concrete  instances  Ci  and  (^2,  and  abstract  instance  A,  we  define  the  behav¬ 
ioral  substitutability  relationship  as  follows: 

is_sub(C'25  C'l,  A)  =  Cl  implements  A  A  C2  implements  A  (3.1) 

This  relationship  may  be  read  as  “(72  is  substitutable  for  Ci  with  respect  to  A”. 
Although  the  behavior  implemented  by  Ci  and  C2  may  differ  in  a  variety  of  ways, 
both  components  provide  the  behavior  specified  by  A  (assuming  the  implements 
relationships  are  justified).  For  a  concrete  template  that  needs  A,  either  Ci  or  C2 
will  satisfy  the  requirement. 

As  an  example,  consider  again  Figure  3.22  on  page  73.  Given  the  relationships 
shown  in  this  figure,  CI_Flipf  lop_l  is  substitutable  for  CI_Flipf  lop_2  with  respect  to 
AI_Flipf  lop  and  conversely,  CI_Flipf  lop_2  is  substitutable  for  CI_Flipf  lop.l  with 
respect  to  AI_Flipf lop.  Any  two  of  CI_FFWSet_l,  CI_FFWSet_2,  and  CI_FFWSet_3, 
are  substitutable  with  respect  to  AI_FFWSet.  Furthermore,  any  two  of  these  three 
extension  implementations  are  substitutable  with  respect  to  Al_Flipf  lop  since  each 
implements  AI_Flipflop.  Finally,  each  of  the  three  extension  implementations 
are  substitutable  for  either  of  CI_Flipflop_l  or  CI_Flipflop_2  with  respect  to 
AI_Flipflop.  However,  CI_Flipf lop_l  is  not  substitutable  for  CI_FFWSet_l  with 
respect  to  AI_FFWSet  since  CI_Flipflop_l  does  not  implement  AI_FFWSet. 
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3.7  Chapter  Summary 


In  T his  clia])! ('r  \v(’  built  on  t Ik'  in {)!’('  formal  rt'lat ions  (h'vt'loix'd  in  C*lia])t(U’  2  to  (\v~ 
fine'  a  usf'fiil  sf't  of  (•om])on('nt  rc'lat ionsliii)s.  St^ction  .d.l  introcliicrd  a  notation  based 
on  I\1-.S()IA*K  and  Ada  for  oncocliiif;  s])(’('ifi(viti()n  ;iiid  iniplciiK'ntatioii  coinixiiu'nts. 
Till'  usps  rolaf ioiisliip.  flcfiiK’d  in  St'ctioii  3.2,  records  any  lorni  of  fix('d  d('p(’nd('n(\' 
ofonn  coniponcnt  111)011  anotlirr.  .Any  tyj)!'  of  coniiioiK'nt  {ahstract  or  concix'to.  ti'in- 
])lai('  or  instaiK'o)  may  use  any  otlu'r  ty])(’  of  coniponcnt.  If  coni])on('nt  C'l  use.s 
coni])i >ncni  tlii'ii  C\  ('itlu'r  rcfcis  directly  or  indirectly  to  C>  (po.ssihly  ini])licitly) 
for  the  purpose  of  dc.scrihiny  hcliavior  in  terms  of  the'  Ix'liavior  di'seribed  hy  C'>. 
Since  the  behavior  (h'.serilx'd  by  a  comiionent  vill.  in  gmieral.  Ix'  infliK'iiei'd  by  any 
other  eompoiK'nt  that  it  uses,  clearly  doenment iny  this  ndat ionslii])  is  important  for 
software  mainlenanee. 

1  he  implements  relat ionshi]).  defiix'd  in  Si'ction  .3. .3,  r(’eords  tlx'  eonformanei'  of 
an  imiileinent  at  ion  eomixinent  to  a  sjx'cifieat  ion  compom'nt.  fb'cording'  this  redation- 
sliij)  is  useful  for  ('stablishiny  substitutability  pro|)ertie.s.  for  stating  its  reciiiirements 
for  \'erifieation  of  eorn'ctness.  and  for  doeumentin,!*;  its  "advc'it  i.sed"  bi'havior.  Tlu' 
imps  relation,  in  t(>rms  of  which  implements  is  didiued.  is  a  relation  dc'fined  over 
til  sfU.s  of  eon(‘rf't('  instance's  and  abstract  instances.  \\('  have  (h'fiiu'd  implements. 
howf'Vf'r.  as  thren'  re'latf'd,  but  distinct,  re'Iationships.  lh('  tlu'('c  signatures  of  the 
implements  redat ionships.  listf'd  in  the'  ledt  column  of  labh*  3.1,  (‘orrespoiul  to:  a 
conenue  instance'  that  implements  an  abstrae-t  instane-e.  a  ceineu'e'te'  te'm])late'  that 
implements  an  abstiae-t  instane*('.  and  a  coiu're'te'  te'm])late'  that  implements  an 
abstract  te'mplate',  re'Spe'ct ive'lv. 

The'  extends  re'latieinship,  elediiu'd  in  Se'ction  3.3.  n'exirds  the'  ce)nfe)rmane‘e  e)f  eine' 
abstraeu  e*omponent  tei  aneitlu'r.  Ib'e’eireling  the'  extends  re'lationship  is  useful  for 
establishing  substitutability  prope'rtie's  anel  feir  spe'edfying  the'  be'luudeir  of  e)iu'  (*om])o- 
ne'iit  in  te'rms  e>f  anothe'r  compeine'iit.  Like'  implements,  the  name'  extends  applies 
to  tlire‘('  re'late'el,  but  elistineg.  re'Iat ie)nshi])s.  The'  thre'c  signature's  of  the'  extends 
re'lat ie luships.  listf'e]  in  the'  h'ft  ce)lumn  e)f  Jable'  3.1,  (’e)rres])e)nel  te):  an  abstract  in¬ 
stance'  that  extends  aneithe'r  abstraeg  instance',  an  abstrael  template'  that  extends 
an  abstrae-t  instaiK*e',  anel  an  abstrael  te'ni])late'  that  extends  ane)the'r  abstrae-t  te'in- 
])late'.  re'spe'ct i\'e'ly.  In  Se'e*tie)n  3. .>.2.  we'  ele’seadbe'el  the'  dire'e“t.  e‘ou])le'd,  and  layered 
ai)])roafdi('s  tei  inpile'iue'nt ing  an  ('Xte'iisieui  e*ompe)neiit  and  prewide'el  example's  of  e'aedi 
approaedi. 

The  needs  re'latieuiship,  de*fineel  in  Se'elieui  3.1.  re'e’orels  a  be'lundeiral  re'ejiiireme'nt 
of  a  e-ouipone'iit  as  a  de'fe'rre'e!  eir  pe)lyme)rphie*  ele'])e'nel('ne‘y.  I'sing  the'  needs  rela¬ 
tionship  to  ('xpre'ss  re'Cjuiie'ment s.  jireve'iits  mme'ce'ssarily  ce)U])ling  im])le'mentatie)ns 
anel  la>‘s  the'  founelatiem  feir  impreweme'iit s  threiiigh  e’ompeine'iit  substitutie)n.  I'se'd  in 


implements 

concrete  component  C  implements  abstract  component  A  iS  C 
provides  an  implementation  of  all  behavior  specified  by  A 

Cl  X  AI 

imps(C',  A)  holds 

CT  X  AI 

for  any  instantiation  C  of  C,  imps(C",  A)  holds 

CT  X  AT 

for  any  instantiation  C  of  C,  there  exists  some  instantiation  A' 
of  A,  such  that  imps(C",  A')  holds. 

extends 

abstract  component  A2  extends  abstract  component  Ai  iff  every 
concrete  component  that  implements  A2  also  implements  Ai 

AI  X  AI 

exts(.42,  .4i)  holds 

AT  X  AI 

for  any  instantiation  A'2  of  A2,  exts(>l2,^i)  holds 

AT  X  AT 

for  any  instantiation  A2  of  A2,  there  exists 

some  instantiation  A'^  of  Ai  such  that  exts(4L2,^i)  holds 

uses 

component  Ci  uses  component  C2  iff  the  meaning  of  Ci  depends 
either  directly  or  indirectly  on  the  meaning  oi  C2 

needs 

concrete  template  C  needs  abstract  instance  ^  iff  C  uses  A  and 
for  all  instantiations  of  C,  C’s  references  to  elements  in  A  are 
replaced  by  references  to  the  corresponding  elements  in  some 
concrete  instance  that  implements  A 

is_sub 

concrete  instance  C2  is  behaviorally  substitutable  for  Ci  with 
respect  to  abstract  instance  A  (is_sub(C2,  Ci,yl))  iff 

Cl  implements  A  and  C2  implements  A 

Table  3.1:  Summary  of  Component  Relationships 
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(■(injunction  witli  tlu'  implements  r('l;it ionslii]).  tlu'  needs  n'lntionsliip  is()lat('s  ini- 
lih'incnt  at  ion  coinponcnts  frotn  ('ttcli  oiIku'  ju  iof  to  syst('ni  int(\u,i’ation  and  ('ncotii  ayt's 
the  (l(‘V(’Io])tn('tit  of  inodtilaily  xauifiahlc  conipotK'nts. 

I  in;dl>',  in  Section  3.0.  \vc  (hditied  tli('  is_snb  ndtttionships  which  holds  whctt 
two  coticrctc  instaticcs  ar('  suhstitiif ahh'  for  out'  atiotln'r  with  rcsiicct  to  a  coininon 
sjiccificat ion  ati  alistract  instance.  Dcsiynint;,  iinphuncnt int;.  and  docnnu'ntin'; 
software  cotniioncnts  iisiny  tin-  implements,  extends,  needs,  atid  wIkui  necessary, 
tlie  uses  ri'lat ionshijis.  is  an  itiiportatit  stej)  toward  (■()tn])()n('nt-l('\('l  niaintenane('  of 
Software  svstetns. 
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CHAPTER  4 


PROGRAMMING  LANGUAGE  SUPPORT  FOR 
BEHAVIORAL  RELATIONSHIPS 


In  this  chapter  we  examine  how  the  component  relationships  described  in  Chap¬ 
ter  3  may  be  encoded  in  modern  programming  languages.  We  primarily  focus  on 
programming  languages  such  as  Ada  and  C-I-+  which  have  an  established  user  base 
and  are  generally  regarded  as  useful  for  constructing  large  component-based  software 
systems.  Complex  programming  languages  such  as  these  provide  many  mechanisms 
which  make  possible  a  variety  of  approaches  to  encoding  software  components.  The 
language  mechanisms  of  primary  interest  are  those  supporting  techniques  for  achiev¬ 
ing  modularity,  information  hiding,  polymorphism,  and  extendibility.  These  four  as¬ 
pects  of  software  engineering  roughly  correspond  to  the  benefits  associated  with  use 
of  the  uses,  implements,  needs,  and  extends  relationships,  respectively. 

Section  4.1  begins  this  chapter  with  a  review  of  the  goals  of  an  approaches  to 
modularity,  information  hiding,  polymorphism,  and  extendibility.  The  following  sec¬ 
tions  discuss  how  programming  language  mechanisms  may  be  used  to  encode  the 
uses,  implements,  extends  and  needs  relationships.  Section  4.6  summarizes  this 
chapter. 

4.1  Language  Support  for  Component- Based  Software  Engi¬ 
neering 

Many  authors  have  written  about  how  programming  languages  can  provide  sup¬ 
port  for  building  reusable  software  components.  Most  detailed  discussions  of  lan¬ 
guage  mechanisms  supporting  component-based  software  focus  on  the  features  of  a 
single  language  such  as  Ada  [Boo87],  C++  [CE95],  Eiffel  [Mey94]  and  RESOLVE 
[Har90].  Some  books  on  object-oriented  programming  languages  (OOPL’s)  com¬ 
pare  how  the  mechanisms  of  different  OOPL’s  support  software  reuse  (for  example, 
[Cox86,  Bud91]).  Edwards  provides  a  detailed  analysis  of  how  well  four  languages 
—  OBJ,  RESOLVE,  Eiffel,  and  Standard  ML  —  support  component-based  software 
engineering  [Edw95,  pp.  165-183].  There  is  a  wide  variety  of  opinions  about  what 
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(■<)iHl)in;ition  of  sjx'cific  iiH’chanisins  Ix'st  su|)])orls  coiiipoiK’iit-hasf'cl  softwaia' 

cneiiifcrii)”.  Xc'vc'it Ik'Icss,  then’  is  ,u,('iu'ial  a,u,r(’t'iiic'nt  that  languagr  iiK'clianisins  that 
siii)])o)t  inofliilaritw  iiifonnat ion  liirlint!,.  polyinorpliisni.  and  ('\t('n(lil)ility  an'  i)arfi(- 
ulai'ly  nscfni. 


4.1.1  Modularity 

Moflnlarity  in  tin'  dosiyii  and  iin])l(’ni('ntalion  of  softwan’  involv('s  i)artitionin,c;  a 
soft  waif  syst  ('in  into  const  it  iicnt  "jiarts  rnodnh's.  1  he  Ix'iicfits  of  inodnlarit\’ ar(' 
well  estahlislx'd.  Modular  dcsiyii  is  a  primary  tool  for  inana,u,in”-  coinpli'xity  nsiiia,  ah- 
straction.  Dccoinposint!;  a  large  system  into  smalh'r,  eoneeptnally  sinijiler  units  makc's 
a  system  specification  easii'r  to  miderstatid  and  implement.  Conijian'd  to  a  monolithic 
implement  at  ion.  a  modular  imph'inetitatioti  should  Ix'  ('asier  to  uiuh'rstand.  test.  d('- 
l)im.  and  maintain.  I  nrt hermore.  if  modules  ar('  w('ll-design('d.  tlx'  modular  approach 
sup])orts  soft  wan'  reus('. 

C'ompoiK'iit-hased  software  engiiu'ering  assumes  that  eomiilex  syst  ('ins  will  he  eon- 
striieti'd  from  software  eonipoiK'iits  nioduh's.  Programming  languag('s  supporting 
this  ap])roaeh  must  tlx'H'fon'  provide'  some  unit  of  modularity  for  d('fiiiing  eompo- 
iK'iits.  lh('  top-down  or  "st  met  lin'd"  aiijiroaeh  to  atialysis  and  d(’sigii  of  software 
systems  heeanu'  iioiuilar  in  the  lOTO's  [,SMC7-l].  This  aiiproaeh  advocate's  finirtinual 
iln-ntnimsitinri  e)f  syste'ins.  Piine  t ieinal  de'ceunjieisitieui  fex'iisi's  on  process  (ibsfnirfinn 
and  h'ads  tei  ope-rat ieiiis  as  the'  jirimary  unit  of  modularity.  With  this  a])])roaeh.  indi¬ 
vidual  ope'rations  .ser\'e  as  components  and  eomponeiit  lihraries  primarily  consist  of 
eolleetioiis  etf  siihroiit ines. 

( )l)jeei-ori('nt e'd  analysis  and  de’sign.  which  hegaii  to  gain  i)o])ularity  in  the  lf)SO  s. 
take's  a  difle'ie'iit  apjireiaeh  tee  ineeelnlarity  which  h’ads  tei  difiere'iit  kinds  of  eoniiionents 
Par<2.  Me'vST.  Poeittk.  'l  lx'  eeh je'ct-orie'iit e-d  a])])roaeh  foense's  on  dofa  (ihstnirfion 
and  de'ee)nii)e)sitie)n  of  syste'ins  hase'd  on  data  striietiire's  rathe'r  than  fune‘tioiialit\-. 
I  he'  jirimary  ratiemah'  feir  the'  ohjeel-euieiitc'd  ap])re)aeh  is  hase'el  on  ol)ser\'atioii  of 
heew  meisi  large'  seiftware  syste'ins  change  (ncr  time.  The  data  struetures  of  systems. 
V  hen  \  ie'we'd  ahst  rae’t  ly.  tend  tee  he  fairly  stahh'  over  time.  Systc'in  funetieuiality. 
heiwe'ver.  tends  tee  change  tee  a  inue'h  greater  extent.  The  oh jee-t-orie'iited  appreiaeh 
\  iews  a  syste'in  eomiieuieiit  iiriiiiarily  as  an  ahstraet  data  type  (.ADT)  which  speeifie's 
a  type',  eiperaiieiiis  on  that  ty]x'.  and  leieal  state  feir  n'liresent ing  the'  value  of  ohjeets  of 
the-  type'.  \\  ith  this  appreeaeh.  ceuniieuie’nts  may  eoiitain  data  struetures  atid  multi])le' 
eipe'ratioiis. 

■Many  inoele'in  preigramming  language's  ])ro\'id(’  meehanisms  feir  eneoding  eomjx)- 
iietits  that  ene-a|)sulate'  heith  data  struetures  and  ojie'iat ieuis.  In  OOPL's  such  as 
Siiimla.  C  Idfh’l.  and  .lawi  the  primary  unit  of  niexlularit\‘  is  the  class.  A  class 
se’i've's  dexihle  dut>-  as  a  me’chainsin  feir  heeth  enea])sulat ieui  atiel  definition  of  nser- 
de’finee!  ty])e's.  C  and  Idfh'l  .su|)])ort  parameteri/ed  classes  (te'iiiplates)  which  are 
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very  useful  for  encoding  the  relationships  described  in  Chapter  3.  In  other  languages 
such  as  Ada,  Modula-2,  and  ML  (all  strongly  typed  languages)  the  mechanisms  for 
defining  modules  and  types  are  distinct.  An  Ada  package,  a  Modula-2  module,  and 
an  ML  module  may  declare  multiple  types  accessible  by  other  components  in  addition 
to  operations  and  local  data  structures^®.  Both  Ada  and  ML  provide  strong  support 
for  parameterized  components  with  generic  packages  and  functors,  respectively. 


4.1.2  Information  Hiding 

Information  hiding,  also  called  encapsulation,  is  a  technique  for  achieving  ab¬ 
straction  whereby  some  features  of  a  component  are  made  inaccessible  to  (they  are 
“hidden”  from)  other  components.  As  with  modularity,  the  benefits  of  information 
hiding  are  well  known  and  most  programming  languages  provide  mechanisms  sup¬ 
porting  some  form  of  information  hiding.  Information  hiding  may  be  used  to  restrict 
and  simplify  the  way  in  which  clients  may  interact  with  implementation  components. 
By  preventing  client  access  to  implementation  details  such  as  data  representations, 
implementations  may  be  changed  without  changing  the  “non-hidden”  interface  of 
a  component.  This  reduces  coupling  between  implementation  components,  supports 
making  localized  changes  without  global  affects,  and  results  in  software  systems  which 
are  easier  to  maintain. 

In  addition  to  simplifying  a  client’s  view  of  a  component,  information  hiding  used 
in  conjunction  with  behavioral  specifications  may  support  re- conceptualization  of  a 
software  component.  That  is,  the  “cover  story”  provided  by  a  behavioral  interface 
description  (a  specification  component)  might  be  quite  different  from  the  description 
provided  by  implementations  of  the  specification.  As  a  simple  example,  consider 
AI_Flipflop  (Figure  3.1)  used  as  the  specification  of  CI_Flipf lop_2  (Figure  3.2). 
AI_Flipflop  not  only  hides  the  INTEGER  model  representation  of  CI_Flipf lop_2, 
it  portraj's  —  we  might  even  say  “lies  about”  —  the  implementation  as  having  a 
BOOLEAN  model.  In  this  case  the  BOOLEAN  model  serves  as  a  simpler,  more  abstract 
cover  story  for  the  actual  representation  of  CI_Flipf  lop_2.  One  of  the  goals  in  the 
design  of  behavioral  interface  specifications  is  to  convey  to  clients  a  useful  mental 
model  of  the  behavior  exhibited  by  conforming  implementations  [Edw95,  pp.  7-12]. 
In  order  to  achieve  simplicity  and  allow  for  a  variety  of  differing  implementations,  the 
mental  model  described  by  a  specification  component  may  be  significantly  different 
from  the  model  of  any  particular  conforming  implementation. 

Programming  languages  provide  a  wide  variety  of  tools  for  achieving  information 
hiding  at  the  component  level.  A  common  approach  is  to  declare  certain  features  of 
a  component  as  “public”  and  others  as  “private” .  Types,  operations,  and  variables 

Although  Ada95  packages  may  export  multiple  types,  only  a  single  extensible  “tagged”  type 
may  be  defined  within  a  package  and  extended  using  inheritance.  With  this  limitation,  the  object- 
oriented  model  supported  by  Ada95  is  similar  to  that  of  C-|— b. 
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\\lii(li  riK’  piililic  iiijiy  l)(‘  (lir('('fly  rcfcri'iiccd  hy  visil)l('  to)  ('li('iit  coch'.  Fcjituic'S 
(locljirofl  jis  ])riv;itc  iirc'  only  visihlo  within  tlio  conipoiK'iit  in  which  then'  an'  dcfiiK'd 
thus  aclii('\inu  infonnation  hidinu;.  In  OOI’I/s.  tlx'  data  n’pre'scntation  for  the  type 
defiiK'd  hy  a  class  is  t\'pically  re'prese'iited  hy  iiistdiicc  vnridhlcs  of  tin'  class.  If  the 
instance  variahles  ai'e  declare'd  as  piivale'.  tlu'n  the'  data  re'presentation  of  the'  class 
is  hidden.  C— —  classf's  may  deline  o])eration.s  and  variahles  with  the  three'  visibility 
inealifie'i's:  public,  private,  anel  protected.  A  variable  eer  eeieeratieni  de-clareel  as 
private  eenly  is  visible'  within  the-  ele-IininK  edass.  A  protected  eejx'ratieen  eer  vari¬ 
able  otily  is  visible  within  the*  eh'Iitiin.”;  e'lass  atxl  all  snb-classe's  (e'lasse's  litd<eel  by 
iidx'ritanee)  of  the'  eh'liniti.e,  class.  .lava  Inis  tlx'se'  thn't'  visibility  e'jite'gorie's  leliis  two 
aehlitiotial  one’s''.  In  Fdfh'I.  all  ehiss  fe'ature's  are-  private'  iinh'ss  tlx'v  are-  explicitly 
eh'clari'el  as  "exiieerte'el"  in  whie'h  case  the-y  are'  ])nblie'. 

.\s  neeteel  above'.  Moelnla-'2  nioeluh's.  .Aela  ])ae'ka,<j,e's.  and  .ML  ineieliile's  inav  eh'fiix' 
and  e'x])ort  limit ijile  tyjie's  unlike'  e-las.se's  in  ineist  OOPL's.  In  tlx'.se'  language's.  ADT's 
enrre'speinel  to  e'X'iieirte'd  type's  with  hieleh'ii  elata  re'im'sentatiems.  Me)eliih\-2  nmelule's 
aixl  .Xela  pae  kage's  e'eiiisist  eif  se'jxirate'  Ix'aeh'r  anel  boely  jiarts.  tv])icttlly  phu'e'fl  in 
se'])arate’  file's.  I  Ix'  re’])re’se’nt at iein  eif  a  .Me)elula-2  oikkjiic  tj/pc  is  hieleh'ii  by  eli'claring 
its  \  i>ible'  I e'pi e'se'iit at  ieeii  as  a  point e’r  in  tlx'  (Icfiiiif ion  mndulc.  the'  Ix'aeh'r  jiart.  anel 
ele’e'larinv  thi'  refe're'ixe'd  data  strix'ture'  in  the'  juivate'  vuplcdidiifdfion  inoddh.  the' 
beiely  part.  .All  .Aela  priralf  ti/jic  is  eh'clare'el  twie'e'  in  an  .Aela  parkape  sped  fi  cat  inn.  the 
Ix'aeh’r  part.  .A  ])ri\ate'  tyjie'  is  first  eh'e'lare'el  in  the’  |)iiblie'  se’e'tiein  wiflxxit  pre)vieling 
a  re’pre’se'ntaiiem.  atxl  tlx'ii  in  the  private  se'e  tiem  with  its  reiire'se’ntatiem.  .Althexigh  a 
e  lie'iii  hieeking  at  an  Aela  jiae-kage'  spe’e'ifieatiein  can  “se'e’"  a  private  tyiie's  re’pre’.se'iita- 
tieeii.  clie’iit  e  eifh’  ehee's  ixit  have’  visibility  tei  any  t^'jx’s.  e)])e’rat ieins.  or  variable’s  eh’e  lare'el 
in  the  |)ii\ate'  se'e  tiem  of  a  pae’kage'  spe'e'ifie'.itiem.  dyjie's.  e)|X’rat iems.  anel  \'ariabh's  eh’- 
e  lare  el  anel  iiiiph’iix’nle’el  in  the'  /x/e'/o/e/e'  hodtp  but  neit  eh’e'lare'el  in  the'  ptiblie'  .se’e'tiem 
eif  the’  jiae-kave’  sjie’e  ifie  at iem  are'  eemiph’te’ly  hieleh'ii  from  clie'iits  eif  the’  package. 

ML  prexieh’s  at  h'ast  femr  elifh'ie’nt  a])i)roae'he's  tei  infeirmatiein  hieliiig  at  the’  meid- 
nh’  h’ve'l  \  110.").  p.  'Fhe'  apiireiae-h  eif  using  ML  sipjidl drr.‘<  tei  hieh'  infeirmatiein 

eeiiitaiix'el  in  .ML  strurf drc.'^  e'eirre’.sjiemels  very  ehise’ly  tei  using  spe’e-ifie'atiein  e'eimpo- 
iie’iits  to  hieh'  infeirmatiein  e-einiaiix'el  in  imiilenx’ntation  e’emiixments  as  slxiwn  in  the’ 
e’xamiih’s  in  fhajite'r  .A  anel  meieh’h'el  by  AC'Tl  [FelwO.'i.  !il.].3..A].  .ML  signature’s  are' 
meieliih’s  that  oidy  may  eeintain  tyjx’  name’s  (with  nei  re’iire’si'iitat iem).  value'  names 
with  tlx’ir  a^soe  iat e’el  ty]ie'  signature'  (but  nei  value),  anel  varieius  eitlx’r  sju'e-ifie-at iems. 
In  ML.  fuix'tieins  are’  tre’ate’d  as  \'ahx's.  .A  \alue'  natix’  anel  tvjie’  signature'  may  e'iflx’r 
111’  an  eiielinary  variable'  anel  its  elata  ty|X’  eir  the’  name'  of  tin  eiiie’i  tit  iem  anel  its  param- 
e'te’f  profile’.  .A  stnxtiire'  is  a  meieluh'  that  mtiy  cemttiin  ly]x'  re'iire'se’iitat iems.  value’s 

iiieliuling  fmx'tiem  imph'nx’ntatiems.  anel  vtiriems  eithe'r  (’h’lnents  iix'lueling  nesteel 
.sub.structiire’s.  I  hits  ii  signature’  niexluh'  e-eirrespemels  tei  a  spe'e-ifie-atiem  e-emipement 

.Ifiwi  >  private  protecteed  is  e'e|iii\';ile’iiT  tei  protecteed  in  C  -S*f .  s  protecteed  tiixl  default 

viot.ilirv  tab'  into  consiele’iation  tlic  .lavti  ''iiae-kage'"  in  wliie-li  the’  e'lassi's  are'  de'fine’el. 
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(with  no  language  support  for  behavioral  specifications)  and  a  structure  module  cor¬ 
responds  to  an  implementation  component.  We  discuss  the  relationship  between  ML 
signatures  and  structures  further  in  Section  4.3. 

4.1.3  Polymorphism 

Polymorphism  literally  means  “many  forms” .  Within  the  context  of  programming 
languages,  polymorphism  refers  to  the  situation  in  which  a  single  name,  such  as  a 
variable  name,  may  be  used  to  denote  values  of  different  types  or  objects  of  different 
classes.  Cardelli  and  Wegner  survey  and  classify  a  variety  of  techniques  for  achieving 
polymorphism  [CW85].  They  identify  the  two  primary  kinds  of  polymorphism  as 
parametric  polymorphism  and  inclusion  polymorphism.  Parametric  polymorphism  is 
achieved  by  using  templates  and  inclusion  polymorphism,  also  called  subtype  polymor¬ 
phism,  is  achieved  by  using  inheritance  and  typically  dynamic  binding  of  operations. 
Note  that  the  term  “polymorphism”  is  frequently  used  specifically  to  refer  to  sub- 
type  polymorphism  with  dynamic  binding  of  operations,  especially  within  the  object- 
oriented  community.  As  do  Cardelli  and  Wegner,  we  use  the  term  in  the  broader 
sense  to  include  parametric  polymorphism. 

Techniques  for  achieving  polymorphism  support  the  design  and  implementation 
of  components  which  are  less  coupled  to  other  components  than  would  be  possible 
without  polymorphism.  This  can  help  in  attaining  system  maintainability,  compo¬ 
nent  reusability,  and  component  substitutability.'  Budd  nicely  summarizes  the  role  of 
polymorphism  as  follows. 

Polymorphism  in  programming  languages  permits  the  programmer  to  gen¬ 
erate  high-level  reusable  components  that  can  be  tailored  to  fit  different 
applications  by  changing  their  low  level  parts.  [Bud91,  p.  88] 

This  characterization  of  polymorphism  also  describes  the  role  of  the  needs  re¬ 
lationship  between  a  concrete  template  and  an  abstract  component  as  discussed 
in  Section  3.4.  Consider  the  implementation  CT_Threeway_l  shown  in  Figure  3.8. 
CT_Threeway_l  provides  an  example  of  parametric  polymorphism.  Since  the  repre¬ 
sentation  of  the  concrete  type  Threeway  is  constructed  from  an  implementation  of 
AI_Flipf  lop  supplied  as  a  parameter.  Threeway  may  be  considered  as  a  polymorphic 
type  describing  many  different  implementations  (forms).  The  different  implementa¬ 
tions  are  all  of  the  possible  instantiations  of  CT_Threeway.  The  operations  Advance 
and  On  defined  by  CT_Threeway_l  may  be  considered  as  polymorphic  operations  which 
manipulate  (flip-flop)  objects  of  many  different  types.  As  we  discuss  in  Section  4.5, 
it  is  also  possible  to  encode  the  needs  relationship  using  subtype  polymorphism. 

By  the  generally  accepted  definition  of  an  OOPL,  all  OOPL’s  include  inheritance 
and  dynamic  binding  and  thus  the  mechanisms  necessary  for  subtype  polymorphism. 
Statically  typed  OOPL’s  such  as  C-|— f,  Ada  (Ada95),  Java,  and  Eiffel  as  well  as  dy¬ 
namic  type  checking  OOPL’s  such  as  Smalltalk  all  support  polymorphism  in  the  form 


89 


of  siilitypc  j)olymor])liisni.  Pamnu'tric  ])()]yinor|)liisiii  is  su])])ni't('d  in  a  varirty  of  lan- 
^^uat!(■^.  ParaiiK'tcri/cd  coiiiponnits  may  Ix'  oncodad  iisiii”  ML  functors.  Ada  <;an('ric 
])arka'.:cs.  CV-  taniplaO's.  and  Liffcl  ^(‘iiaric  cla.ssas.  .\ot('  that  Ada.  C'+  +  .  and  Eifh'l 
land  s(‘\‘(’ial  otln'r.  primarily  r('S('arcli.  lan.ymyyc's)  inovich'  snpjxnt  foi'  hotli  snl)t\'p(' 
and  ])araniatric  |)o!ymoi'phism.  TIk'  moclianisms  sn])i)ortin<j;  tlursa  two  forms  of  poly¬ 
morphism  ma\’  1)(‘  used  in  comhinat ion  to  achieve  useful  results.  We  i)r(n  id('  exam])les 
of  the  comhined  use  of  parametric  polymorphism  and  inheritance'  in  Chapter  5. 


4.1.4  Extendibility 

Lxte'iulihility  refers  to  how  ('asy  it  is  to  ('xtc'iid  the  functional  hehavior  of  at) 
existing  com])oti('nt-l)ased  system  and  thus  how  easy  it  is  to  extend  the  hehavior 
dc.'crihcfl  hy  software  con)])on('nts.  In  St'ction  2.1.1  w('  discussed  tin'  iiu'vitahh'  nee'd 
for  chaimcs  to  software'  .syste'ins.  Pe'ife'e't ive'  mainte'iiatie’e.  whieL  adelre'.sse's  chanj’e's 
in  fnne-tional  rceinire'ine'nts.  ae'e’onnts  feer  the'  large'st  peertion  e)f  all  maintentme'e'  eosts 
LBSP'<()_.  Since'  iK'w  fiine-tiefiial  re'e)nire'me'nts  ne-arly  always  e'all  feer  aelelitional  syste'in 
fune  tionality  (as  e)])pe).se'el  te)  re'ehie'cel  syste'in  fmie-tieinality).  extenelihility  is  a  highlv 
wilne'd  e  haiae'te'iist ie-  eef  seeftware'  syste'ins. 

■Any  Software  foi'  whie’h  the'  seetire'e'  e’oeh'  is  ax'ailahh'  is  "e'xte'iielahh'  in  the'  se'iise' 
that  the'  soiiree'  eetde-  esui  lee'  meeelihe'el  tee  aelel  ne'w  fune't ionality.  Heeweve'r.  the  goal 
of  elc^iyninu  anel  im])le'me'nting  e'xte'iielahle  e-e)m])e)ne'nts  is  tei  he-  ahh'  to  e'Xte'iid  the' 
fune  tionality  eif  e'xisting  e-eemieenie-nts  with  minimal  elisruptieni  tee  syste'ins  that  use 
tho''C  eoinpone'iits.  Whe'ii  e'xte'iieling  the'  fune't  ionality  eif  an  e'xisting  e-omieonent  or 
e'om])oiicni-l>asf>d  syste'in.  we'  want  tee  meeelify  the'  e'eeele'  eef  e'xisting  e-eunpenients  as  little 
a-  pos-,il)lc.  Minimi/ing  e'hange's  t ee  e'xist ing  e-ennieeene'nt  e-eeeh'  minimize's:  introdiu'tieen 
ofhims  and  niicxpe'e  te'el  he'havior.  re'te'st ing  and  re'e-e'ctilie-ation.  anel  possibly  ex])e'nsive' 
s\>tcin  re'-hnileP  (e'.g..  e'xte'iisive  re'e-eunpilat ieui). 

lo  some'  e'xte'iit.  the'i'e'  is  a  traeh'  eeff  he'twe'e'ii  informat iein  hieling  and  e'xte'iielihil- 
ity.  F.xteiieling  a  e'omieone'iit  that  make's  its  inte'rnal  eh'tails  acce'ssihh'  (puhlie-)  imiy 
he  e'a^ie'r  anel  result  in  a  mene'  e'llie  ie'iit  imple'nie'ntatie)n  eef  the'  e'xte'iieh'el  fune  tieinalitv. 
llowcve'i'.  as  elisciisse'el  in  Se'e'tieeii  3.0.2.  the'i'e'  is  a  prie'e'  tei  ])ay  for  sne'h  we'ak  e'lie'ajesu- 
latioii.  A  numhe'r  of  aulluers  have'  elise  usse'd  this  traele'-eeff  in  the  eonte'xt  eef  OOPL's 
SCtD o.  M\\!)().  Sny8G;.  1  he'  laye-re'e!  apjeroae'h  tee  im])le'me'ntat ie»n  extension  eh'se-riheel 
in  Se'ction  3.o.2  preivieles  an  e'xam]>le'  eif  how  stremg  ene'aiisnlat  iein  may  he'  maintaine'el 
whih'  still  sup])orting  e'xte'iielihility. 

In  gene'ial.  language'  nie'e'hanisms  snpiieirt ing  nioelnlarity.  information  hieling.  anel 
polyinor])hisin  are'  also  nse'ful  feir  supporting  e'xte'iielihility.  The'  language  meehanism 
iiio"!  a^''Ofiatcfl  with  e'xte'nelihilit\'  is  inhe'iit aiu'e'  whie'h  is  jirennele'el  in  eine  feirm  or 
another  hy  all  ()()P1,  s.  Inhe'ritane'e'  is  a  eeinve'iiie'iit  me'ehanism  for  ele'se'iihing  heiw 
eiiie  e'oinponent  elillcrs  from  aneithe'r.  Heiweve'r.  inheritanee'  is  iise'el  for  many  eliflerent 
pnrp(K('s  in  aeielition  to  e'xte'iision  eif  e'eiiniione'iits.  In  pre'.se'iiting  a  taxonomy  of  the' 
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uses  of  inheritance,  Meyer  describes  12  distinct  “valid”  uses  for  inheritance  [Mey96]. 
Under  the  general  category  of  model  inheritance,  Meyer  includes  subtype  inheritance 
which  does  not  involve  inheritance  of  data  representations  or  operation  implementa¬ 
tions.  Subtype  inheritance  is  used  to  express  and  enforce  a  conformance  relationship. 
We  refer  to  this  use  of  inheritance  as  specification  inheritance.  The  most  common 
use  of  inheritance  involves  inheritance  of  data  representations  and  operation  imple¬ 
mentations.  This  use  of  inheritance  is  often  called  subclassing.  We  refer  to  any  use  of 
inheritance  that  falls  into  this  category  as  implementation  inheritance.  What  Meyer 
calls  “extension  inheritance” ,  a  uses  and  subtyping  relationship  between  implemen¬ 
tations,  and  “implementation  inheritance”,  a  uses  relationship  based  on  inheritance 
but  not  implying  subtyping,  both  fall  into  this  category. 

Many  authors  have  written  about  the  problems  that  can  arise  from  using  one 
programming  language  mechanism,  inheritance,  for  several  distinct  purposes  [Tai96, 
Cla95,  Edw93,  Coo90].  Several  newer.  OOPL’s  address  these  problems  by  using  dis¬ 
tinct  language  mechanisms  for  encoding  (structural  aspects  of)  specification  inheri¬ 
tance  and  implementation  inheritance.  Java  is  the  most  widely  used  language  that 
has  different  mechanisms  for  specification  inheritance  and  implementation  inheri¬ 
tance.  We  discuss  these  aspects  of  Java  in  Sections  4.3.4  and  4.4.  Other  new  OOPL’s 
that  also  use  different  language  mechanisms  for  specification  and  implementation  in¬ 
heritance  include  Theta,  a  language  primarily  based  on  CLU  [LCD‘''94],  Sather  1.0, 
a  language  based  on  Eiffel  [SOM94],  and  Pizza,  a  superset  of  Java  [OW97].  Note 
that  unlike  Java,  Theta,  Sather,  and  Pizza  all  support  parametric  polymorphism  in 
addition  to  inclusion  polymorphism. 

The  hierarchical  library  structure  introduced  into  Ada  with  the  1995  language 
revision  provides  a  unique  approach  to  component  extension  not  found  in  other  pro¬ 
gramming  languages.  In  Ada,  any  library  unit  (a  package,  subprogram,  or  generic 
unit)  may  be  extended  by  a  child  unit.  The  visibility  of  a  child  unit  includes  full 
visibility  of  its  parent  unit  including  the  parent’s  private  section.  The  presence  of  a 
child  unit,  however,  does  not  affect  the  parent  unit  or  any  components  which  depend 
on  the  parent  unit.  Child  and  parent  units  may  be  compiled  separately  and  adding 
a  child  unit  does  not  require  recompilation  of  the  parent  unit.  The  child  unit  mecha¬ 
nism  is  orthogonal  to  Ada’s  inheritance  mechanism.  However,  as  we  demonstrate  in 
Chapter  5,  these  two  language  mechanisms  may  be  used  in  combination. 

4.2  Encoding  The  uses  Relationship 

As  discussed  in  Section  3.2,  the  uses  relationship  represents  a  fixed  dependency 
between  two  software  components.  If  component  A"  uses  component  F,  then  X  in 
some  way  depends  on  Y.  The  uses  relationship  provides  no  information  on  how  Y 
is  used  by  A^;  but  without  access  to  component  the  meaning  of  component  A^  is 
incomplete.  With  some  programming  languages,  the  source  or  object  code  of  F  must 
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lx-  Jivailahlf-  ill  order  to  conipile  the  source  ((xh-  of  A'.  ()th<-r  laii,u,tia,”('s.  liowi-ver.  may 
Hot  r('()iiire  that  the  eorh-  of  )  lie  a\'ailal)I('  to  A  until  syst(-m  int('ji;rat ion  time  (link 
time )  or  even  until  runt ime, 

Sonu-  ])royiammine  lanyuaxes  n-ciuiri-  exjilieit  eneodiii”'  of  the  uses  n-lat ionshi]) 
hetweeii  comixiiients.  The  visil)ilit\-  rules  of  tlu-  lanxna,<;('  largely  dictate  what  is 
rcfinired  for  one  component  to  refer  to  eh-ments  d('fined  hy  another  eomjxment.  Iti 
the  ('X  a  tuples  in  C  hapti-r  •{.  a  uses  el  an  si-  in  context  section  direct  K’  eneodi-fl  tlx-  uses 
relationship.  In  the  ease  wlx-re  A'  uses  we  assimu-d.  for  simplicity,  that  all  (-lements 
defined  in  the  interface  of  }'  could  he  n-feri-need  diri-etly  within  A'  without  name 
(jiialificat ion  (unh-ss  neei-ssary  to  rt-soKi-  o\‘('rloadinti,).  In  souk-  lan.uiua,L!,('s  tlu-rt'  is  a 
sej)arat('  mechanism  for  allowing  ahhreviatc-d  reh-renct-  to  compoiu-nts  and  elements 
defined  within  other  components. 

In  some  cases,  a  uses  elausi-  iti  the  C'h;i])t('r  3  ('xamph-s  comi'ws  rt'diiiiflant  in¬ 
formation  that  may  he  di-dnced  from  otlu-r  parts  of  the  conpxnient.  For  (-xamph-. 
sinct-  the  needs  elanse  alwaws  (-ntails  a  uses  r('l;tt ionship  wt-  could  h;n-('  omittt-d  all 
uses  clauses  for  compotients  snhse(inentl\-  inchid('d  in  needs  clauses.  Also,  uses 
clauses  could  he  omitted  for  e:ieh  comixuient  mentiom-d  in  a  re-exports  clause-.  W'v 
choose  to  n-einin-  a  uses  clause-  for  e-ach  uses  relationship  tee  make-  it  perfectly  e-h-ar 
in  tlx-  Source-  coeh-  on  what  otlx-r  ceimixiix-nts  a  xi\en  comjxnx-nt  dire-ctly  elepends. 
I  his  information  is  e-ritieal  for  e-omjxnx-nt  nnde-rstandinx.  mainte-nane-e-.  aixl  iirogram 
analysis,  anel  should  not  he-  eihse  nre-el  in  am'  waw 

( )ne-  eharae  t e-rist ie-  that  furthe-r  elist in^nislx-s  ameniL!,  ])re)xianmiing  lanp,ua”e’s  sup- 
poriiiix  eomjione-nt-hase-el  seifiware-  e-nxine-erinx  is  the-  elistine-tion  he-twe-en  ee)m])e)ne'nts 
anel  elaia  tyiies.  In  .-\ela  aixl  lanyuaxe-s  hase-el  ein  Xiklaiis  Wirth's  MeielnIa  (Me)elnla-‘2. 
Me.elula-.d.  Ohe-ron.  atiel  ()he-re)n-2  [\VirS2.  H\Vf)2]).  a  e-e)m]x)nent  (a  iiaekaxe  ew  moel- 
nle-t  is  not  a  elata  tyiie.  In  the-se-  lanxnage-s.  the  uses  re-latieaishi])  is  e'xjilicitly  e-ne-eiele-el. 
In  tnost  OOPI.'s'A  lx>we'ver.  a  e-emipone-nt.  lypie-ally  e-alle-el  a  class,  is  a  iise-r-elefine-el 
t\pe-  fioin  whie  h  eihje-cts  may  he-  ele-e'lare-el.  Partly  as  a  re-sult  of  this  elist ine-tieui.  meist 
( )( )I  I.  s  elo  ixil  ie-e|uirt-  a  class  tei  e-xplie’itly  list  all  e)the-r  e  lasse-s  that  it  elirectly  uses. 

In  .\ela.  ;i  with  e  lanse-  plae  e-el  in  the  ceeiite-xt  se-e-tieen  eef  a  |)aeka,e;ie-  e-ne-eiele-s  the-  elire-e-t 
uses  re-latieeiishi])  he-twe-en  twei  pae  ka.xe-s.  If  an  Aela  pae-kaxe.  say  pae-kage  A',  nee-els  tee 
re-fe-r  tee  seeme-  e-le-me-nt  ele-fiix-el  in  aix)the-r  pae  kage-.  say  pae-kage-  the-n  A'  must  iix-Inele- 
a  w’ith  e  latise-  naming  }  ' In  ge-ne-ral.  an  .Aela  ])ae-kage-  eenly  may  he-  ceetnpile-el  when  all 
pae-kaue-s  npeui  whie  h  it  ele-jee-nds  have-  he-en  ceemjeile-el  aixl  are-  a\ailahle- in  the-  preegram 
lihrarv.  This  strale-gy  Ix-lps  e-nsnre-  that  struetural  e-rreers  are-  ele-te-e-te-d  as  e-arly  as 

■Aei.i  e  .Vel.iO.) ! .  Mn(liil;i-.i.  axel  ()l)e’i'oii  all  lieive-  l;ixxti;ix('  xie-e'liaiiisms  sil]>|)e)i't in.y  eel)  je’e-t-eerie-iite-el 
procraiiiniiii!,'.  I  lie'  sii])])i)ri  tlie'Sf  lemgnaye’s  ]iie)vi<l(-(l  for  nxxliilariiy  has  Ix-e-u  e-jirrie-el  eeve-r  from 
tlx-ir  non-ohjoct-orie-nti-el  |)r(-e-ursors.  .AeleiS.g  for  .Aela  anel  .\Ioehila-2  feer  Olx-re)!!  anel  Moelnla-.A. 

‘  '.All  .Alla  I)arka'.;i-s  iin])li(  il Iv  have-  visihility  tee  the-  spe-e'ial  pae-kage-  Standard  whie-h  ele-tinr-s  .Aela’s 
hnih-in  lyix-  anel  o)>r'r;itions.  .Also,  pae-kage-s  ele-fining  e-hilel  units  (elisciisse-el  in  Cliajete-r  o)  leave- 
vi-it)iliiy  to  ihi'ii  lean-lit  tttiit  Ixit  elo  tiot  re-einire-  a  with  with  ehmse-  tiatnitig  tlie-ir  ]iare-tit.  Itiste-arl. 
the  i>.'in-tii  unit  n/itni-  is  ;i  pre-fix  of  the-  e-hilel  ttnit  txitne-. 


possible.  Note  that  Ada’s  use  clause  allows  components  to  reference  public  elements 
defined  in  with’ed  packages  without  using  their  fully  qualified  names.  Chapter  5 
includes  examples  showing  the  use  of  Ada’s  with  and  use  clauses. 

In  the  Modula  and  Oberon  family  of  languages,  the  IMPORT  clause  “imports” 
(makes  visible)  elements  from  another  module  in  much  the  same  manner  as  Ada’s 
with  clause.  In  Modula-2  and  Modula-3  it  is  possible  to  selectively  import  features 
exported  by  another  module  by  using  a  clause  of  the  form  “FROM  M  IMPORT  X”  where 
M  is  a  module  name  and  X  is  an  explicitly  exported  (public)  element  defined  in  M.  A 
module  that  includes  this  form  of  IMPORT  clause  may  refer  to  the  imported  element 
X  directly  instead  of  using  the  qualified  name  M .  X.  Oberon  does  not  have  this  form  of 
IMPORT  clause  since  its  designer  believed  that  explicit  qualification  of  imported  names 
is  preferable,  especially  when  many  modules  are  involved  [RW92]. 

In  typed  OOPL’s  such  as  Java  and  Eiffel,  there  are  two  ways  in  which  one  class 
may  have  a  fixed  dependency  on  another.  First,  class  X  may  be  a  subclass  of  class  Y, 
in  which  case  X  uses  Y.  This  form  of  dependency  is  encoded  using  an  inheritance 
mechanism  such  as  the  inherit  clause  in  Eiffel  and  the  implements  and  extends 
clauses  in  Java.  Second,  X  may  be  a  client  of  Y  without  being  a  subclass  of  F.  In 
this  case,  X  uses  the  name  Y  as  a  data  type  for  declaring  an  object  or  parameter.  (In 
Java,  could  also  be  used  within  X  for  type  casting.)  When  is  a  client,  but  not  a 
subclass  of  F,  most  OOPL’s  do  not  require  any  sort  of  “import  list”  that  in  a  single 
place  names  all  fixed  dependencies  on  other  components.  Meyer,  in  describing  Eiffel 
[Mey88,  p.  211],  and  Stroustrup,  in  describing  C-f-|-  [Str93,  p.  416],  both  note  that 
such  an  import  list,  would  be  redundant  and  could  be  automatically  generated  by  a 
tool.  Without  the  aid  of  such  a  tool,  however,  a  maintainer  must  search  for  class  names 
throughout  a  given  class  in  order  to  determine  all  inter-component  dependencies. 

To  avoid  possible  confusion,  we  note  that  Java  does  have  an  import  statement. 
However,  the  purpose  of  Java’s  import  statement  is  to  allow  a  class  to  refer  to 
other  classes  using  abbreviated  names  rather  than  fully  qualified  names.  Thus  Java’s 
import  statement  serves  essentially  the  same  role  as  Ada’s  use  clause. 

Like  most  other  OOPL’s,  C++  does  not  directly  support  encoding  of  the  uses 
relationship  between  a  class  and  the  other  classes  of  which  it  is  a  client  but  not  a  sub¬ 
class.  However,  a  common  C++  idiom  is  to  use  the  preprocessor  directive  #include 
to  textually  insert  a  C++  header  file  containing  a  class  interface  into  another  file  that 
uses  the  interface.  If,  by  discipline,  each  class  is  associated  with  a  single  header  file 
that  declares  its  interface,  then  #include  may  be  used  to  encode  the  uses  relation¬ 
ship  between  two  classes.  If  client  class  X  #include’s  the  header  file  for  class  F,  and 
we  assume  that  at  link  time  A"  will  get  linked  to  the  class  definition  for  Y ,  then  it 
is  reasonable  to  consider  the  # include  directive  a  direct  encoding  of  the  uses  rela¬ 
tionship.  Note  that  in  the  case  of  specification  components  represented  as  abstract 
classes,  there  need  not  be  an  associated  class  definition  to  a  class  header  file. 
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Ill  suiniiiari/c.  in  most  OOPL's  n  module'  is  n  class  which  is  a  data  type'.  In  this 
ca'-c.  tlir  S('t  of  fixed  deiieiich'ncies  of  compom'iit  A  con('S])onds  to  all  data  type's 
re-fereiie’i'd  within  A  e'xe-e'ptiny  the'  tyi)e  A’  ilse'lf  and  ct'rtain  hnilt-in  tyjx's.  The'se 
lancuaye's  elo  neit  re'e|nire'  e'xplicit  e'liceieliny  e)f  the'  uses  rt'lationshi])  anel  a  te)e)l  may  Ix' 
ne’e  e'»ary  to  ieh-ntify  and  summarize'  such  de'pe'iiele'ne'ie's.  Lan,[!;na<;e's  stie'h  as  Aela  and 
the'  Moelnla  family  etf  lanynaye's.  in  \\hie’li  the'  mee’hanisms  feir  (h'fininy  ce)m])e)ne’nts 
anel  elata  type's  are'  elistine  t.  pre)\'iele'  eiire'e't  siippeirt  for  e'lie  exlin,”;  the'  uses  re'latiemship 
in  the'  form  eif  an  impent  list . 


4.3  Encoding  The  implements  Relationship 

In  Se'e  tion  d.'?  we-  eh'fine'el  the'  implements  re'lationship  whie'h  is  hase'd  on  the 
imps  rclatieiii  eh'fine'el  in  Se'e^tiein  2.3.1.  d  he'  me)tivatie)n  feir  e'stahlishiny  anrl  ch'arh' 
eloeanne'iitine  the'  implements  re'latieinship  was  eli.se-ti.s.se'el  in  the'se'  sections  anel  also  in 
Se'e  tion  2.1 .  In  this  se'e-tion  we’  dise'iiss  he)w  varie)iis  proerammiii”  hmetittye'  me’chaidsms 
may  he’  nse’d  tei  enedeh'  the'  cldinr^'  ih;it  the’  implements  relat ieinshi])  heilels  hetwe’cn 
two  edm])one'nts  an  imple'inentatiem  anel  a  si)ee'ifieatie)n. 

The’  iirimary  re’asems  feir  e’xi)lieitly  e'ne-e)elin,y  the’  implements  re'lationship  are': 


•  tei  provieh'  infeiiniat iein  nse'el  lei  de'te’rndne’  a])])re)])riate'  ce)m])e)ne’nt  e'e)mi)e)sitie)n. 

•  to  inelie  ate'  an  eihliyat iein  fdi'  e'enifoiinane'e'  che'ekin.u;.  anel 

•  tei  he'l])  elocume'iit  the’  e'laime'el  he’havieir  e)f  imi)le'mentatie)n  ce)m])e)nents. 

.At  edinponi’nt  inte’yratie)!)  time,  a  re’e-eirel  eif  the’  implements  re-latieenship  may 
he'  nse'el  hy  a  linke'f  eer  eithe’f  teieil  tei  dete’rmine'  whie'h  coni|)e)ne'nt  ce)mpe)sitie)ns  are 
ap])ri ipriate'  and  whie-h  :ire'  neit .  l  eir  e’xamph'.  if  cenicre'te'  ce)m])e)nent  A  needs  ahstrae't 
e-ompone'nt  )'  anel  e'eme're’te'  e'ennpone'iit  A'  implements  ihe'ii  it  is  ap])re)i)riate'  feir 
A  to  he'  instantiate’el  with  Z.  An  e’ne-eieh'el  implements  relationshi])  alsei  may  reepure 
a  edinpili’r  to  ehe'e'k  striu'tnral  e'enifeninane'e'  he'twe'e'ii  the'  re'late'el  im])le'mentatie)n  anel 
spe’eifie  ation.  Similarly,  the'  implements  re'lationship  may  ge’nerate  preiof  e)hli,yatie)ns 
for  a  ve’rifieation  loeil  eir  te’stiny  re’einire'ments  in  eneh'r  te)  aief  in  confirmin”  he’havioral 
e-onformane-e'  he'twe'e'ii  twei  e'ennpeine'iits.  By  asse)e'iatin,y  an  imple’ine'ntatieni  with  a 
s])e'e  ifieat ion  to  whieh  it  must  e-einfenni.  the'  implements  relatienishi])  alsei  serve’s  as 
eloe  ume'iitatiein  nse'fiil  to  a  seiftware’  e'liyine'e'r  weirkiny  elire'e  tly  with  the  sonre'e  coeh'  of 
an  imiile’me’ntatieiii. 

■"till  lire'vity,  we  v.'ill  ivjiie'allv  use'  till'  |)lirasi'  "ene-eieliui;  an  iiiijih'iiiriit.s  re'lationsliip"  to  iiu’an 
more  ae-e-iirafi'lv  •■I'licoernit;  thr  (-1(11111  ei/  an  imploninits  n'laf ionslii])" . 
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4.3.1  The  implements  Relationship  and  Coupling 

Recall  from  Chapter  3  the  components  CI_Flipf  lop_2  and  CI_Flipflop_3  (Fig¬ 
ures  3.2  and  3.5,  respectively).  Both  components  implement  AI_Flipf  lop  (Figure  3.1) 
and  both  describe  identical  operational  behavior.  The  difference  between  these  two 
components  is  that  CI_Flipflop_3  uses  AI_Flipflop  while  CI_Flipf  lop_2  does  not. 
There  is  no  reason,  in  general,  why  a  concrete  component  must  depend  on  an  abstract 
component  which  it  implements.  However,  many  of  the  language  mechanisms  most 
useful  for  associating  specifications  and  implementations  couple  implementation  com¬ 
ponents  to  the  specification  components  which  they  implement.  Thus  in  most  lan¬ 
guages,  encoding  the  relationship  C  implements  A  requires  that  C  uses  A.  We 
discuss  a  few  interesting  exceptions  to  this  in  Section  4.3.5. 

There  are  several  reasons  why  it  is  useful  for  an  implementation  component  to 
depend  on  a  specification  component  which  it  implements.  Stating  a  (claimed)  im¬ 
plements  relationship  in  the  source  code  serves  as  documentation  identifying  a  spec¬ 
ification  of  the  component’s  implemented  behavior  (although  not  necessarily  all  of  the 
implemented  behavior).  For  documentation  only  purposes,  however,  an  implements 
statement  may  be  treated  as  a  semantically  irrelevant  comment  ignored  by  compilers 
and  other  processing  tools.  That  is,  there  need  be  no  syntactic  or  semantic  depen¬ 
dency  just  to  achieve  this  documentation  objective,  and  thus  no  uses  relationship 
between  the  two  components. 

As  with  CI_Flipf  lop_3,  a  concrete  component  may  refer  to  specification  (non¬ 
programming)  elements  of  an  abstract  component  which  it  implements.  Assuming  no 
renaming  of  types,  operations,  or  variables  (programming  elements)  defined  in  the  ab¬ 
stract  component,  this  level  of  reference  is  sufficient  for  expressing  the  correspondence 
(abstraction  relation).  As  we  discussed  in  Section  3.3,  recording  the  correspondence 
is  an  important  aid  to  justifying  the  implements  relationship.  In  this  case,  the 
implementation  uses  the  specification,  but  not  in  the  normal  “compilation  depen¬ 
dency”  sense.  A  typical  compiler  could  process  such  an  implementation  component 
without  examining  the  implemented  specification  component.  In  RESOLVE/ Ada95, 
discussed  in  Chapter  5,  specification  elements  are  encoded  as  comments  which  are 
ignored  by  Ada  compilers. 

One  of  the  main  reasons  programming  languages  require  implementation  com¬ 
ponents  to  be  coupled  to  interface  specification  components  is  to  support  structural 
conformance  checking.  That  is,  language  mechanisms  useful  for  encoding  the  imple¬ 
ments  relationship  —  most  notably  inheritance  mechanisms  —  typically  require  the 
compiler  to  check  that  the  structure  of  the  implementation  conforms  to  that  of  the 
specification.  We  discuss  conformance  checking  below  in  Section  4.3.2. 

Despite  these  reasons  for  making  an  implementation  dependent  upon  the  specifi- 
cation(s)  that  it  implements,  there  are  some  potential  disadvantages  to  this  common 
approach.  For  example,  if  the  content  of  a  concrete  component  must  explicitly  name 
any  abstract  components  that  it  implements,  then  establishing  a  new  implements 
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n'hif ioiiship  (not  clcriv;il)l('  fioiii  ('xistiii.u,  rcUit i()iislii])s)  for  ;iii  ('xistiii”  concn'to  coin- 
poiK'iit  will  t\  i)ic;illv  rcfjuin'  modifying  tlic  iniplc'iiu’iitnt  ion's  soiirct'  code  nnd  poton- 
tinll\- ('xpf'iisivc  n'C  ()ni])il;it ion.  A  few  l;uitt;ua”;('s  sncli  as  ML  and  C'++  with  siynatiin's 
151(07  iii'ovidc  snjjport  for  ('ncndin,i>;  the  implements  ladtitionshi])  without  nxitiir- 
inu  that  iiiiplcnu'niations  ladcr  to  the  s|)('(  ificat ion  ('oin])onf’nts  they  iinph'inont .  We 
consider  an  example  of  this  in  Section  I.d.d. 


4,3.2  Conformance  Checking 

Prior  to  i)lacinn;  a  concrete  conipoiumt  into  a  c()in])on('nt  lihrary  and  making  it 
availahh'  for  client  ns('.  we  obviously  w;int  to  have  some  confich'iice  that  it  will  hehave 
a'^  "aflvertised"  when  inte,yrat('d  into  a  system.  A  comj)on('nt's  adv('rtis('d  behavior 
is  tli('  behavior  specified  by  the  abstract  components  which  it  implements.  Confor¬ 
mance  checking  is  tin'  proc('ss  of  (h'termininu;  to  some  lev('l  of  confidence  that  a 
concrete  com])on('nt  correctly  describes  ati  implementation  of  tin'  Ixdiavior  sp('cifi('d 
by  an  al)stract  comixaient  which  it  implements.  In  order  for  an  implements  nda- 
tionshi])  to  b(’  jnstifi('d.  tlx*  stinctina'  mid  Ixdiavior  of  tlu'  concri'ti'  comjxiix'nt  must 
conform  to  that  of  the  abstract  compoix'nt. 

for  most  pro,mammin,y  laiiRnayes.  checkin, u,  structural  conformance  is  a  ndatividy 
straightforward  task  carried  out  by  a  conpiiler  or  inti'rprc'ti'r.  1  his  invoha's  ensnr- 
ine  that  all  tyjies.  opertitions.  and  \';iri;ibles  specifii’d  in  tlu'  abstract  compoix'nt  art' 
imitcht'cl  by  compatible  concrete  typt's.  o]x'r;it ions,  and  vtiriables  in  the  (clit'iit-visible 
pjirt  of)  the  concrt'te  comiionent .  The  type  systt'in  of  the  lan.ynage  determint's  tht' 
rules  for  conformatice.  For  hm.yna.yes  that  sn])])ort  typt'  extt'iision  (inclusion  poly- 
inoriihism)  and  ]);irameteri/ed  types  (parametric  polymorphism),  tht'  rnles  for  dt'ter- 
mininu  wlnit  ctmstitntt's  a  match  can  bt'ctimt'  stimt'what  ctimplt'x  [CAVS").  LW'O  l]. 

.\s  wf'  ha\t'  discnsseil  in  t'jirlier  cha])tt'r.s.  \'('ry  fV'w  ])rt),[;;rammin,y  lan.yna.yes  in- 
cliuie  mechanisms  sn])])t)rt iny  spt'cificatitxi  of  ctimptinent  bt'ha^■it)r.  Excejititms  are 
primarily  rt'st'arch  hm.yna.yt's  snch  tis  015.1  [Gt),u;S  l]  and  RKSOIA'F  [SWO  l].  mtire 
common  apiiroach  for  ctmst  met  in,”  bt'havioral  intt'rface  s])t'cificat  itins  (abstract  ctim- 
ponents)  is  to  inteyratt'  tht'  irst'  of  intlt'iit'ixlent  s])ecificatit)n  anti  inpilt'mentatitin  lan- 
,ynaye,''  S\\!)l.  DLOn.  .ItmOO.  LvIlK15( )87].  In  ]>ractict'.  htiwevt'r.  tht'  mtist  ctimmtm 
approatdies  for  encodin,”  tht'  bt'htu'itir  spt'cifit'd  by  an  intt'rface  rt'ly  tin  informal,  non- 
riyoroiis  descriptions  of  comiionent  Ix'lnivior.  rnfortnmitt'ly.  inforimil  spt'eifications 
art'  nsiially  imjirt'cist'  anti  ambi,yntins.  'J’ht'rt'ftirt'.  rt'ast)nin,y  alxnit  tht'  Ix'havior  of  a 
concrt'ti'  coni]xtnt'nt  which  sonieont'  claims  implements  snch  a  s])t'cificatit)n  niav  be 
fault  w 
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Figure  4.1;  A  One-To-One  Implementation- To-Specification  Relationship 


4.3.3  One-to-One  Relationships 

One  of  the  hrst  programming  languages  designed  specifically  to  support  modular 
(component-based)  software  development  was  Modula-2  [Wir82].  In  Modula-2,  soft¬ 
ware  components  are  encoded  as  modules  which  may  be  divided  into  two  parts:  a 
definition  module  and  an  implementation  module.  A  definition  module  contains  sig¬ 
natures  of  types  and  operations.  An  implementation  module  contains  data  structures 
and  operation  implementations.  A  definition  module  may  be  used  to  represent  an  ab¬ 
stract  instance  and  an  implementation  module  may  be  used  to  represent  a  concrete 
instance.  The  Modula-2  compiler  checks  to  ensure  that  an  implementation  module 
structurally  conforms  to  a  definition  module  of  the  same  name.  Thus,  in  Modula- 
2  there  is  a  one-to-one,  by-name  conformance  relationship  between  implementation 
and  specification  modules.  This  relationship  naturally  serves  to  represent  the  imple¬ 
ments  relationship  when  other  means  are  used  to  enforce  behavioral  conformance 
between  the  implementation  and  definition  pair. 

In  Ada,  a  software  component  is  typically  encoded  as  a  package.  An  Ada  package 
has  two  parts:  a  package  specification  and  a  package  body.  These  serve  the  same  roles 
as  Modula-2’s  definition  and  implementation  modules,  respectively.  As  with  modules 
in  Modula-2,  there  is  a  one-to-one,  by-name  conformance  relationship  between  a  pack¬ 
age  specification  and  a  package  implementation.  Unlike  Modula-2  modules,  however, 
Ada  packages  may  be  generic  (parameterized).  Generic  package  specifications  and 
package  bodies  may  be  used  to  encode  template  components.  Figure  4.1  depicts  the 
one-to-one  implements  relationship  between  a  specification  component,  such  as  a 
Module-2  definition  module  or  an  Ada  package  specification,  and  an  implementation 
component,  such  as  a  Modula-2  implementation  module  or  an  Ada  package  body.  As 
depicted  by  the  thick  arrow,  this  is  also  a  uses  relationship  since  the  implementation 
components  have  visibility  over  and  depend  upon  (for  compilation)  their  correspond¬ 
ing  specification  components. 
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I  he  iniplf'niciitntioii-to-six'cificntion  n’hit ioiisliips  ('itcodc'd  usuig  M()dula-‘2  mod- 
ul(’>  aiifl  Ad;i  help  ix'diicr  llic  conijliiig  l)('t\\'('('ii  iinplc'iiK'iit ation  (•()ini)oiif'iits. 

I-Di' rxainplc.  if  iinplciiioiilation  coiiipoiK'nl  C  needs  s|)(‘(  ificat ion  coinpoiient  A.  thou 
C  iiia\'  rofor  to  .1  and  ho  (■oni])iI('d  witliont  tin'  oonx'spondin.ii,  iinplonn'iitation  of  .-1 
pro>ont,  I  nrilior  nioro.  tlio  oonoroto  oonii)onont  that  implements  A  may  Ix'  inodific'd 
and  rocoinpilod  without  ro(|nirin,L!,  roooin])ilation  of  olic'nt  oonipononts  wdiioli  use  .4. 
Hov,f'\or.  if. 4  is  a  Modnla-2  dofinition  nuxlnh'or  an  .Ada  ])aokago  s]>ooifi(ation,  a  coin- 
ponf'iit  lihrary  oontaininy  .4  may  oidy  hav('  a  singh*  im])lomontation  oomponont  that 
(‘iioodos  tho  implements  ndationship  with  .4'-'.  Tims,  tho.so  langnago  moohanisms. 
motlulos  aixl  i)aokagos.  lack  sn])|x)rt  foi'  mnlt  iph'  implomontations  of  a  single  si)ocifioa- 
tion.  Fni't liorinoro.  Modnla-2  nxxhdi's  and  .Ada  package's  (prior  to  tlx'  ]90o  langnage' 
revision)  are  not  easily  ('xtendahh'.  Tlx'  snece'.ssors  to  Modula-2.  Olx'ron  [R\\'92]  and 
Modida-.A  llai'S2  .  aiul  the  199-)  le'vision  to  .Ada  [Intdoh]  all  inelnde  nx'ehanisms  that 
snp])oit  multiple  implementations  and  compoix'nt  exte'iision. 


4.3.4  Many-to-One  Relationships 

In  Section  1.1  we  discusst'd  inlu'iitanee  aixl  (dtisses.  and  state'fl  that  sitecifieation 
inlx'i  itance  is  nsefid  for  encoding  tlx'  implements  aixl  extends  rehuionships.  One 
of  the  manv  uses  of  inlx'iitance  is  tlx'  ('xpression  aixl  enforcement  of  a  eonformanee 
rehit ifuiship  Ix'twf'e'ii  two  d;it;i  tyjx's.  \\  Ix'ii  a  eomjxment  s]X'cifi('S  or  imph'inents  a 
sni'jh  data  ty]x’.  as  does  a  chiss.  inheritance'  intiy  he'  use'el  te)  e'.xjire'ss  a  e'onformanee 
re'hitiemship  lietwe-en  two  e'emiiieine-nts.  For  e'xtunph'.  if  edass  D  is  eh'rive'el  frexn  (inherits 
from )  e  hi'is  H.  t  hen  edtiss  J)  is  a  suhedtiss  eif  B  aixl.  in  most  e  ase's,  expeirts  all  eijie'i  at  ions, 
varitihh's.  e'.xe-e])tie)ns.  ete-..  I'xpeirte'el  hy  B.  Thus,  e  la.ss  D  strued uralh’  eemforms  tei 

e  hi^v  B'--. 

\\ith  s])e'e  ifieat ion  inlx'ritaix’e'.  the’  hase'  edtiss.  frenn  whiedi  e'emfeiiining  suhe’lasse’s 
are'  de'iiveel.  eloe-s  neit  proviele-  any  imiile’ine’ntat iem  eh’tail.  This  is  anahigous  to  a 
Moeluhi-2  elefinition  meieluh’  atxl  (the’  pnhlie'  ])art  eif)  an  .Aela  ]);x'ktige'  s])e'e’ifie'atie)n. 
In  ()()P1.  te’rms.  a  e  lass  whie  h  eloes  neit  j)re)\  iele'  a  type  re'])re’se'nt at iein  aixl  imjih’men- 
tatieins  for  all  its  eipe'rations  is  e'filleel  ati  (ihstiact  class  eir  an  ahstcaci  hasc  class,  Meist 
oori.'s  h  iiHT'lianisins  for  (aicodiiin;  al)stra(‘t  classos  or  tlnar  (Hjui\‘al('nt .  In 

a  (  la^s  will)  at  l(‘ast  ont'  viriiial  funrfioj}  is  an  abst  ract  class.  In  Ada.  a  package 
f‘Xi)orting  an  abstract  typo  coriT'sjFonds  to  an  abstract  class.  In  Eifbd.  an  at)stract 
cko^  is  calk’rl  a  (l(f(rrffl  chiss. 

'‘\;)ri()in  fooP  and  tricks  may  Ix’  us(t1  to  (TiT'iimA-tMit  th('  lairi^uagt'  limitation  of  onr  ])arkap;('  l)od\- 
l)f'r  packaeo  sjxT’ificat ion  within  ati  Ada  componf'nt  library.  HowenT'r,  within  a  singh'  cxrrutahh' 
sy^tf-ni.  tlh  if'  m;iy  only  bf'  oiu’  ])af'k;ig('  body  jx'r  parkagf'  s])rrifi(’ation. 

OOPL  s  allow  a  dcrivcfl  clas.-^  D  to  “liirh'”  inh(a‘itfHl  (>j)f'rations  of  bast'  (dass  B.  If  this 
tnrhnjrpK-  i-  tIkti  D  will  not  conform  to  B. 
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Figure  4.2:  A  Many-To-One  Implementation-To-Specification  Relationship 


An  abstract  class  that  provides  no  implementation  detail  is  useful  for  encoding 
an  abstract  component  that  exports  a  single  type.  A  concrete  class,  a  class  that  fully 
implements  its  data  representations  and  operations,  is  useful  for  encoding  a  concrete 
component  that  exports  a  single  type.  The  structural  aspects  of  the  implements 
relationship  may  be  encoded  using  specification  inheritance  by  deriving  a  concrete 
class  from  an  abstract  class. 

Figure  4.2  depicts  two  (claimed)  implements  relationships  among  two  concrete 
classes  and  an  abstract  class.  Each  concrete  class  is  derived  from  the  abstract  class 
shown  at  the  top  of  the  figure.  Although  a  language’s  inheritance  mechanism  may 
be  used  to  encode  this  tj^pe  derivation,  the  concrete  components  need  not  “inherit” 
anything  from  the  abstract  class.  Each  concrete  class  must  override  all  abstract  op¬ 
erations  specified  by  the  abstract  class  with  structurally  conforming  and  fully  imple¬ 
mented  operations.  Additionally,  each  concrete  class  must  provide  a  data,  structure  to 
represent  the  exported  type  of  the  concrete  class.  Note  that  when  specification  inheri¬ 
tance  is  used  to  encode  the  implements  relationship,  the  implementation  component 
uses  the  specification  component  that  it  claims  to  implement.  This  is  indicated  by 
the  thick  arrows  in  Figure  4.2. 

In  contrast  to  the  one-to-one  implementation-to-specification  relationship  depicted 
in  Figure  4.1,  inheritance  supports  encoding  many-to-one  implements  relationships. 
Any  number  of  concrete  classes  may  be  derived  from  and  implement  a  single  ab¬ 
stract  class.  Using  this  approach,  a  component  library,  and  even  a  single  executable 
program,  may  include  different  concrete  components,  each  of  which  explicitly  imple¬ 
ments  a  single  abstract  component.  Thus  this  use  of  inheritance  supports  (better 
than  the  mechanisms  of  Modula-2  and  Ada83)  encoding  the  implements  relation¬ 
ship  and  component-level  maintenance.  The  RA95  discipline  (discussed  in  Chapter  5) 
and  RESOLVE/C-f- h  discipline  both  use  specification  inheritance  for  encoding  the 
implements  relationship. 

In  Section  4.1.4  we  pointed  out  that  some  newer  languages  use  different  mech¬ 
anisms  for  specification  inheritance  and  implementation  inheritance.  Currently,  the 
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nu)>T  |)()]>iihn'  of  tl)osr  la]i,c!;iin,i;('s  is  Java.  In  addition  to  classrs  \vlii(“li  inav  hr  ah- 
strar't  or  {*onc*rrt(\  Java  incliuh'S  inhi'/arf's  wliicli  aro  similar  to  ahsti'act  rlassos.  Tn- 
lik(‘  Ja\-a's  ahstrart  (Jassrs.  lio\vrv(M\  int (M’facf's  may  only  incliuK'  al)stract  oporations 
((■alh‘d  ahsti'art  nu'thods  in  Java)  and  constants,  Ja\’a  interface's  de'fiiu'  striU'tiiral 
com])onf'nt  int e'l'face's  ancl  sf'i  vf'  as  a  basis  foi'  spc'cific'ation  inl)('ritanc‘c. 

Ja\’a  s  keyword  implements  is  nse'd  for  s])('cifi(‘atioii  inh('ritancc  only  while'  the 
k^'yword  extends  ma\'  he*  iise'd  for  spe'cifie'at ion  e)r  imple'mcntatie)n  inlicritancc^k  In 
a  Java  ejas^  or  inte'rfae-e.  the'  extends  clause'  cne-ode's  the  traditional  fe)rm  e)f  inhe'ri- 
tance'  found  in  man\'  OOPL  s.  Ilowe've'r,  a  class  may  e)nly  ‘’extend"  e)ne'  e)tlie'r  class. 
I  his  limits  Java's  inii)le>mcntatie)n  inhe'ritaiu’c  te)  inluiifdvrr.  On  the'  otlu'r 

haiifl.  a  Java  eJass  may  “implement'’  e)ne'  e)r  me)re'  interfaen's  and  a  Java  iiite'rfae^e'  mav 
“extend  e)nc  e)r  more'  intf'iJae’e's,  I  liiis  Java’s  spce‘ifie‘atie)n  inhe'ritane’e'.  ciu'ode'd  \)y 
an  extends  clause  in  an  inte'rfae-e'  e)r  an  implements  eJaiise'  in  a  class.  sup])orts  ;/////- 
frj^h  ij)hr  jifnnn.  Multiple'  iidicrit ane‘e'.  whieJi  e)fte'n  Icaels  te)  prohle'ins  wluui  uscel  for 
im])h'nie'ntation  inhe'ritancc.  ele)e's  not  e*ause'  the'  same  ])re)l)le'ms  whe'ii  use'el  feu*  spccifi- 
catie)!!  inhcritaiu’c.  Java’s  use'  of  elistinel  langmyye'  mechanisms  te)  su])port  these  two 
eliffe'rcnt.  and  sonu'time's  e‘onflie*t iii.u;,  use's  of  inhe'ritance'  is  an  imi)rove'nie'nt  over  the 
nua-e'  traelitional  a])proaeJi  e)f  usin^  e)ne'  inheritane-e'  mechanism  for  both  })urpose's. 

In  Ja\a,  an  abstiae’t  instane’e'  e'X])e)rt in^u;  a  sinyh'  ty])e'  may  be'  e'lie^ode'd  bv  an  inter¬ 
face'.  A  e*oncre'te'  instanea'  e'X])ort iii.c;  a  sin,i;ie'  type'  may  be'  cne’exle'd  by  a  (‘oneuT'te'  class 
(a  cla-;s  with  no  abstiaeu  nie'thods),  Tsiii.c;  this  sti’ate'gy.  the'  struelural  aspe'eUs  of  the 
implements  re'lationship  may  be'  e'ne‘e)ele'el  ce)in'e'nie'ntly  with  an  implements  clause 
in  a  e’oiu’i'e't ('  eJass  that  name's  an  inte'iJae'e'.  whieJi  the'  ce)ncre'te'  eJass  implements. 
Fiyaire'  1.3  shows  the'  Java  inte'rfae-e'  AI_Flipflop  followe'd  by  the'  Java  cone're'te  class 
Cl _Flipf lop_.3.  J  he'se'  are'  the'  Ja\’a  e'lie'odin.ys  e)f  the'  absti'ael  instane’c  shown  in  Fig¬ 
ure'  .).!  and  the'  e*e)ne’re't e'  instane*e'  shown  in  hi^iire'  3.o.  Xe)te'  that  the'  paraniete'r  te) 
Toggle  and  Test  (of  the'  e'X])e)i'te'el  type)  is  implielt  in  Figure'  J.3  sine'c  Java  uses  the' 
traelitional  obje'eU-eerie'iit e'd  ne)tatie)n  for  me'thoel  eleclarat ions  anel  inve)e*ati()ns. 

De‘N])it('  Java  s  sup])e)rt  for  e*e)nve'nie'nt ly  ene’e)eling  the'  strueTural  aspects  of  the' 
implements  re'latie)nshi]).  as  shown  in  Figure'  J.3.  Java  lae‘ks  suppe)rt  fe)r  e'ncoeling 
a  me>re'  ge'iie'ral  implements  relatie)nshii).  A  Java  class  e)idy  can  define  a  single 
e'xte‘nelal)le'  ty])f'.  I  liiis.  a  Java  eJass  e-anne)t  de'fine  twe)  re'late'd  ty])e'S.  sueJi  as  Point 
anel  Line,  beeth  e)f  whieJi  may  be'  e'Xte'iiele'd  using  inlie'ritance'.  This  limitation  is 
e‘e»mmon  te)  the'  e)bje'e-t-e)rie'nte'el  paraeligm.  whieJi  use's  a  single'  meeJianism.  typicallv  a 
e  la--,  te)  define'  both  ce)mpone'nts  anel  programmer-de'fine'el  ADT's.  Me'eJianisms  siieJi 
a^  Ja\'a  jnnhfif/f s  anel  CM-T  Jridid  fiinrftons  pre)viele'  ine'h'gant  nu'ans  for  working 
aroiinel  thi-  limitation  in  ine)st  situatie)ns. 

Ja\'a  s  lack  e)f  sup])ort  fe)r  ])aranie'te'ri/e'd  eJasse's,  te'm])late's.  i)re'sents  a  me)re'  se'- 
rie)us  limitatie)!!.  \'arious  ielioms  exist  for  “simulating’’  tem])late's  in  Java  [OWOTj. 

*  W'f  coiiK'd  tlic  t('niis  ‘•iiTij>lfMiieMits*'  and  "vx\rn(\s"  IxTore'  lookin,^  at  Java.  Tlienr  use  hv  .lava 
rrinfdif  Tv  oiii-  hrlif'f  that  the'se'  are'  natural  te'rins  for  eonv('\'ing  the*  int(MKl('d  rc’lat i()ns}iij)s. 
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//  AI_Flipf  lop ,  java 

public  interface  AI_Flipflop  { 
//  modeled  by  BOOLEAN 
//  exemplar  ff 
//  initially  ff  -  FALSE 

public  void  Toggle  ( )  ; 

//  ensures  ff  -  NOT  #ff 

public  boolean  Test  (); 

//  ensures  Test  =  ff 

} 


//  CI_F1  ipflop_3  .java 

public  class  CI_Flipf lop_3 
implements  AI_Flipflop  { 

private  int  state  =  0; 

//  convention  0  <~  state  <=  255 
//  exemplar  ff_rep 

//  correspondence  ff  =  (( ff_rep .  state  MOD  2)  =  1) 

public  void  Toggle  ()  { 

state  =  (state  +  1)  %  256; 

} 

public  boolean  Test  ()  { 

return  {(state  %  2)  ==  1); 

} 


Figure  4.3:  Java  Encoding  of  CLFlipflop_3  implements  ALFlipflop 


However,  using  such  strategies  to  encode  a  template-to-template  implements  rela¬ 
tionship  leads  to  extremely  awkv^ard  and  often  inefficient  code.  Some  researchers 
have  proposed  the  addition  of  templates  to  Java  [BLM96,  OW97]. 

4.3.5  Many-to-Many  Relationships 

As  we  noted  in  Section  2.3.1,  the  imps  relation  is  a  many-to-many  relation.  There¬ 
fore,  the  implements  relationship  is  a  many-to-many  relationship  in  the  following 
sense.  Many  different  concrete  components  may  implement  a  single  abstract  com¬ 
ponent;  and  a  single  concrete  component  may  implement  many  different  abstract 
components.  The  first  case,  multiple  implementations  of  a  single  specification,  is  a 
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Specification 

Specification  ^ 

Module  1  j 

^  Module  2  J 

implements  1 

Implementation 

Implementation 

Module  A 

Module  B 

I*iu:ur('  1.-!:  Mniiy-lo-Maiiy  Iin])l(M]iontatic)ii-T()-Si)ocifi(*at ion  Rc^lationships 


(‘oininon  situation  and  ('ssf'iitial  for  (*oin])on(Mit-l('V(d  niaintf'nancT  of  ('01111)0110111  hasf'd 
systrins  (both  softwan'  and  hardware'  syst('nis).  Tlu'  inlK'ritanoo-hasf'd  approach  dis- 
oiissf’d  in  Se'otion  4.3.  !  sii])])orts  iniiltiph'  iniphniiont ations  of  a  single'  s])ooifi(*ati()n. 

I !]('  se'fond  oaso,  multiple'  spe'oifie-at ions  of  a  single'  iniple'ine'ntation.  arise's  iniplioitly 
from  s])e'cifie‘at ion  e'xte'iisioii  (re'oall  K(|nation  2.1)  and  also  may  he'  nse'fiil  to  provide' 
di>tine  t  inte'rfaoe's  or  “vie'ws"  of  a  single'  im])le'me'ntation. 

It  is  possible  to  oxplioitly  e'ne'oeh'  implements  rolationships  among  a  single'  con- 
cre'te'  e'ompenif'iit  and  more'  than  one'  al)stract  com])one'nt.  For  oxani])le*.  in  program- 
mini:  language's  that  support  imilti])lo  inlu'rit ance'.  a  concre'te'  class  may  inlu'rit  from 
multiple'  abstract  classes.  In  Java,  a  concre'te'  class  may  include'  an  implements  clause 
that  name's  more'  than  e)ne'  inte'rface'.  In  this  situatiein,  strueg urally  identical  methods 
may  (but  lu'e'd  ne)t)  be  de'fine'd  in  and  ’inhe'rite'd**  from  more'  than  one'  inte'rface.  Fig¬ 
ure'  4.1  de'])icts  a  sini])le'  many-to-many  ini])le'me'ntal  ion-to-s])e'cification  scenario.  In 
this  e'xample'.  the'  coneue'te'  com])e)ne'nt  e'lie-ode'el  as  iniple'ine'ntation  module'  A  imple¬ 
ments  (jvfl  uses  both  abstract  ceimjionents,  siie'cification  module's  1  and  2.  Iniph'- 
nu’ntation  module'  A  must  conform  tei  beith  sjie'cifie'ation  module's  and  nun'  be  use'd 
whe're'  im])le‘me'nt at  ions  eif  e'ithe'r  or  both  specificatie)ns  are  re'Cjuire'd.  As  in  Figure'  4.2. 
the'  uses  re'lat ionship  be'twe'e'ii  im])!e'nu'nt at iein  anel  s])e'cificatie)n  come's  from  em])lov- 
ing  an  inhe'iit ance'  nie'chanism  to  e'licode'  the'  implements  relationslii]). 

Fncofling  an  implements  claim  with  any  me'chanism  that  couple's  an  im])le'me'n- 
tation  to  a  spe'cificat ion  has  seime'  disadvantage's.  Inhe'ritance'  is  the  primary  example' 
of  such  a  me'e-hanism.  Foi'  e'xam])l(',  to  encode’  a  iie'w  implements  re'latieinshij)  for 
an  e'xisting  concre'te'  ce)m])e)nent .  perhaps  one'  in  obje'ct  code'  form  in  the'  comjieuient 
lil)!  ary.  re'ejiiii'e's  a  source'  code'  change'  and  I’e'ceimpilation  of  the'  concre'te  com])one'nt. 
Baumgartne'r  and  Russo  pre'sent  an  exani])l('  of  how  this  preibh'in  might  arise  in  j)rac- 
tice'  in  the'  coiite'xt  e)f  OOP  [PRO/.  \\  2.1].  The'  solution  tlie'v  ])i'e)])e)se’  and  inpih'inent 
for  — 'BRDT^  and,  with  Laiife'r.  for  Java  [LBROG]  ce'iite’i's  arounel  sfrudunil  ('onfor- 
jiifiDf'f  of  comjionents.  With  strueUiiral  confeirmance'.  a  class  does  neit  ha\'e'  to  name 
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the  interface^^  to  which  it  conforms  as  is  required  with  inheritance.  At  component 
integration  time,  the  compiler  determines  whether  a  class  conforms  to  an  interface 
by  comparing  its  structure  (public  names  and  signatures)  to  the  structure  of  the  sig¬ 
nature.  A  similar  structural  comparison  is  performed  by  ML  in  determining  whether 
an  ML  structure  (an  implementation  component)  conforms  to  an  ML  signature  (a 
structural  specification  component).. 

With  the  structural  conformance  approach,  an  implementation  component  does 
not  need  to  be  coupled  to  a  specification  component  that  it  implements  in  order  for  an 
instance  of  client  code  that  needs  the  specification  component  to  use  the  implemen¬ 
tation  component.  Therefore,  an  existing  implementation  component  does  not  need 
to  be  modified  in  order  for  it  to  fulfill  new,  and  possibly  unforeseen,  requirements. 
Furthermore,  this  strategy  clearly  supports  many-to-many  implements  relationships 
among  concrete  and  abstract  components. 

As  with  the  other  approaches  discussed  in  this  chapter,  language  mechanisms 
supporting  structural  conformance  do  not  address  behaAdoral  conformance  between 
components.  Furthermore,  structural  conformance  does  not  require  any  language 
mechanisms  to  explicitly  record  the  implements  relationship  as  does  inheritance. 
As  a  result,  it  is  possible  for  two  components  to  “accidentally”  conform  structurally 
but  not  conform  behaviorally.  Laufer  et.  ah,  propose  the  use  of  properties  to  ad¬ 
dress  the  problem  of  accidental  conformance  [LBR96,  p.  6].  Properties  are  dummy 
methods  with  “well  known  names”  that  encode  semantic  information.  For  example, 
the  property  “LIFO”  might  be  included  in  abstract  and  concrete  classes  for  stack 
components. 

A  more  powerful  and  flexible  solution  to  this  problem  is  to  use  independent  map¬ 
pings  between  components,  which  describe  how  the  behavior  of  one  component  con¬ 
forms  to  that  of  another  component.  As  we  discussed  in  Section  3.3,  recording  the 
correspondence  (abstraction  relation)  between  two  components  documents  how  the 
behavior  described  by  one  component  may  be  understood  and  justified  as  conform¬ 
ing  to  the  behavior  described  by  another  component.  In  the  examples  in  Chapter  3 
(Figures  3.5,  3.7,  3.8,  3.11,  3.18,  and  3.27)  the  correspondence  is  recorded  in  con¬ 
crete  components  and  implicitly  associated  with  the  abstract  component  named  in 
the  implements  clause.  Furthermore,  in  each  case  there  is  an  implicit  mapping  of 
each  element  of  the  abstract  component  to  its  corresponding  implementation  element 
in  the  concrete  component.  This  approach  couples  a  concrete  component  to  the  ab¬ 
stract  component (s)  that  it  implements  and  fixes  the  set  of  abstract  components 
that  may  be  used  as  client-level  descriptions  of  the  implementation.  It  also  fixes  the 
way  in  which  the  concrete  component  is  interpreted  as  conforming  to  an  abstract 
component.  To  add  new  relationships  or  modify  existing  ones  requires  modifying  the 

their  proposal  for  Baumgartner  and  Russo  introduce  a  language  construct  called  a 

signature,  to  which  classes  may  conform  structurally  without  inheritance.  In  their  proposal  for  Java, 
Java  interfaces  serve  this  purpose. 
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I'imirf'  l.o:  Iiifh'ixMiflf'iit  Mappiiit^s  BcMwchmi  SjxH’ificat ions  and  Iin])I('ni(Mitati()ns 


(•onor('t{M‘()in])on('nt  r\'('n  tlion.t;!)  t ln‘ opfM’at iona!  l)('lia\'ior  tin' {■oni])()n(nit  iniphniunits 
(lof\^  not  f*liain:;(\ 

An  alt  ('mat  i\'f'  approach  is  to  rcx'ord  confoiananot'  rolat  ionsliips,  siu^li  as  iniple- 
nionts  anrl  extends,  in  a  s(’parat('  inodnlt'.  Tins  ap])]’oa(*h  is  nsc’d  1)\'  tin'  fniu'tional 
lanuuaec’  ()nj  C7(),f:;Sr)^  and  is  inod(‘l(Hl  hy  inf ('rprdaf ion  inoppiiufs  in  tlir  ACTI  inod(d 
of  snftwaro  snhsyst (nns  [I'xhvf).),  Jjf.lO].  In  OB.I,  a  niodnl('  (‘an  Ix'  (dtlun’  an  ohjrrf  or 
a  fhfoj'jj.  An  ()B.l  ohjf’ct  dr'fiiurs  typos  (calh'd  soiis  in  OBJ)  and  assoriatod  oj)- 
(‘lations.  An  OBJ  th(‘or\'  pro\*id(\s  an  al)strac‘t.  axiomatic  dc'seription  of  behavior, 
J  Ini''.  ( )BJ  objf'cts  and  tln^orif’s  (‘orrerspond  to  concrc'tt’  and  abstract  (‘oin])ononts. 
rf'sjxM-t ivrjy.  An  OBJ  riar  (h'scribc’s  how  a  niodnl(\  (Jth(M'  an  ()l)joct  or  a  theory, 
conforms  sfmianti(‘ally  to  a  thf'ory.  I  hns,  a  vif‘w  may  b('  ns(vl  to  df'scrilx'  how  an 
objcf  t  implements  a  th('or>-  or  how  a  thc'ory  extends  anotlu'r  tln'orv.  In  ACTI. 
an  iiitf'i  prct  at  ion  map])iny  plays  a  siniilat'  rohx  An  iitt(n'pi'(Jat  ion  ma])])in,i;'  (hJiiurs  a 
corn‘>pfHid(mcf'  Ix’twcHm  two  abstract  inslan(‘f's,  (\\])lainin,i;  how  om^  abstract  instanc(' 
can  b(‘  int (‘ri)r(n (hI  as  satisfying  the*  IxJiavior  d(\s(‘rib('d  by  the  otlu'r. 

]  iuuH'  }..)  shows  how  two  abst i'a(‘t  compomMits.  Specification  Module  1  and  2. 
could  bf'  r(Jat(‘d  to  two  coinponf'iits.  Implementation  Module  A  and  B.  with 

four  inde])eiKhmt  *‘ma])pin^L!;  units  .  In  this  exam])l(\  (*ach  of  tlu'  four  ma])])ini!;  tinits 
could  (h‘S(‘rib('  a  differemt  implements  riJat ionshij)  IxMwcxm  the  two  compoiumts  to 
which  it  r(Tei’s.  As  tin'  arrows  in  hi,ynr('  4. a  im])ly.  the  ma])])in,t;  units  nJer  to  (d('p(md 
on)  tin'  sp('(‘ifi(‘ation  and  ini])l(mi(mtat ion  moduhrs.  but  not  tlu^  otlnu*  way  around. 
J  liii^  an  imi)huiuMit  at  ion  ih'chI  not  r(’f(M'  to  a  specification  that  it  implements  and 
vic(‘  vfU'sa.  1  his  strat(\u;y  allows  luuv  ('X])licit  conformance'  n'lationshi])s  to  Ix'  adch'd  to 
a  comj)oiK‘nt  library  without  modifyin^y  existin^y  com])oiK'nts  which  mav  Ix'  iin'olved 
in  tin'  iK'w  r('lationshi])S. 
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Figure  4.5  shows  two  different  mapping  units,  Mapping  y  and  Mapping  z,  relat¬ 
ing  Implementation  Module  B  and  Specification  Module  2.  This  is  possible  be¬ 
cause  a  mapping  unit  can  rename  various  elements  in  describing  how  once  component 
conforms  to  another.  Both  OBJ  views  and  ACTI  interpretation  mappings  support 
renaming.  As  a  more  concrete  example,  assume  that  Specification  Module  2  in 
Figure  4.5  describes  a  stack  abstraction  such  as  AT_Stack  shown  in  Figure  3.10  on 
page  57.  Now  assume  that  Implementation  Module  B  describes  an  implementation 
of  a  deque,  a  double-ended  queue,  including  the  deque  operations:  Enqueue_At-Front, 
Enqueue-At_Rear,  Dequeue_At-Front,  and  Dequeue_At_Rear.  Mapping  y  could  map 
Enqueue_At_Front  and  Dequeue_At_Front  to  the  stack’s  Push  and  Pop  operations, 
respectively.  Describing  a  different  way  to  implement  a  stack.  Mapping  z  could  map 
Enqueue _At -Rear  and  Dequeue_At_Rear  to  Push  and  Pop,  respectively.  To  complete 
the  picture,  Implementation  Module  A  might  be  at  typical  stack  implementation 
with  only  operations  Push  and  Pop.  In  this  case  Mapping  x  would  describe  the  obvious 
mapping  with  no  renaming.  Specification  Module  1  might  describe  the  behavior 
of  a  bag  (multiset)  container  with  operations  Insert  and  Remove.  Then  Mapping  w 
would  map  Push  and  Pop  to  Insert  and  Remove  respectively. 

The  independent  mapping  approach  provides  significant  flexibility.  However,  it 
adds  complexity.  The  implements  relationship  is  no  longer  a  simple  binary  relation¬ 
ship  as  modeled  by  imps  in  Section  2.3.1.  Also,  when  a  mapping  unit  is  allowed  to 
rename  types  and  operations,  it  plays  an  important  operational  role  at  component 
integration  time.  In  addition  to  selecting  an  implementation  component  to  instanti¬ 
ate  a  template,  the  system  developer  may  also  need  to  select  an  associated  mapping 
unit  to  identify  the  appropriate  operation-to-operation  bindings.  OBJ  uses  default 
views  (default  mappings)  to  simplify  component  composition  [Gog86,  p.  21], 

4.4  Encoding  The  extends  Relationships 

In  Section  3.5  we  defined  the  extends  relationship  which  is  based  on  the  exts 
relation  defined  in  Section  4.1.4.  Documenting  the  extends  relationship  records  the 
claim  that  any  implementation  of  one  specification  will  also  be  an  implementation  of 
another  specification.  Thus  if  abstract  component  A2  extends  abstract  component 
Ai,  then  all  implementations  of  A2  will  also  be  implementations  of  Ai.  Thus  A2  must 
specify  all  the  behavior  specified  by  Ai  and  usually  will  describe  additional  functional 
behavior  not  specified  by  Ai .  The  motivation  for  establishing  and  clearly  document¬ 
ing  the  extends  relationship  is  to  foster  the  development  of  new  components  with 
enhanced  capabilities,  but  which  remain  compatible  with  existing  systems  and  their 
requirements. 

In  many  respects,  the  extends  relationship  is  similar  to  the  implements  rela¬ 
tionship.  Both  are  many-to-many  behavioral  conformance  relationships.  Many  of  the 
issues  discussed  in  Section  4.3  pertaining  to  encoding  the  implements  relationship 
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nKu  (MK'ocliiifj,  thf‘  extends  rc^lationshi]).  Foi'  (\\ani])l{\  wliih'  extends  is  not 

a  (lf'])f'iKl(‘iK\v  rc'lat ionshi]),  lik('  implements,  it  is  (\)si(\st  to  ('iicoflf'  as  such.  Lik(' 
implements,  extends  is  dc'fiiH'd  as  a  niany-to-niany  ixdationsliip.  Mowovca*.  most 
lanmiae(’  na'cliaiiisins  iisrfiil  for  oncodins  extends  ar('  tlu'  same'  as  tlioso  us(y1  for 
('iir-odiny  implements  and  only  sn])|)ort  inany-to-onn  extends  r(dationslii])s.  \\V  do 
not  addr('ss  tlu'sc’  issiirs  in  ch'tail  in  this  srrtion  sinor  tlu'y  wf'rc'  dis(*uss('d  at  l(Miti;tli 
in  S('otion  4.3. 


1  h(^  most  {'otnmon  way  to  caicoch’  tin'  extends  n^lationship  in  mod(M’n  ])r(\u;ram- 
mine  lanmiaeos  is  to  nsc'  an  iidi('ritanc('  or  inlKM'itanc('-lik('  lan.e,ua,i;('  nun'lianism.  In 
S(‘rtion  3.0.1  w(' disctissf'd  tlu'  fli(f('ron(’(\s  hcMw^uai  th('  moanine;  of  extends  and  tluu'f- 
f(‘ot  ty])ifally  afliirwd  hy  nsin.y  iiduaitanccs  44i('  extends  ndationsliip  holds  \)c\\yvvn 
two  spf'cifioat ions  wIkmi  oik'  conforms  to  anotluas  Nddtlu'r  of  th('  two  specifications 
iK'f'd  numtion  tin'  othf'r  (as  witli  AI.FFExt  in  Fi,i;urc  3.1o  which  extends  AI„Flipflop 
in  I'iuiin'  3.1).  I'.sf'  of  inlu'ritancc'  always  imi)lics  a  uses  rc'lationship.  If  abstract  class 
Aj  inherits  fiom  abstraci  class  ,4i  (ty])('  Aj  is  (haavc’d  from  typ(’  A\)  thcai  A^  uses 
.1;.  As  disciissf'd  in  Sc'ction  3.0.1 ,  tlu'rc  arc  advantae;('s  and  disafivanta,e('s  to  using  a 
coiipling  n4ationship  to  (oicoch'  th('  extends  r(dat ionship. 


S('\*fO'a1  iK'WfM'  OOPLs  such  a  Java  ])rovid(‘  distinct  language  mc'chanisms  for 
adrliiie  ariditional  ehuiuoits  to  abstrac't  “int('rface-oidy  '  com])onents  and  for  adding 
additional  (d('mfMits  to  im])lem('nt  at  ion  components.  For  ('xarnphe  Ja\'a's  extends 
keyword.  wIkmi  usf'd  to  lodatc^  two  Java  int('rfac('  com])onents.  j)rovid('s  a  form  of 
spocifi(‘at ion  inlu'rit anc(\  l  igun'  4.0  shows  an  ('xam])h'  of  this  use  of  Ja\’a  extends. 
I  ho  intf'rfacf’  AI_Flipf lop„With„Set  shown  in  tlu'  bottom  of  this  figure  extends 
AI_Flipflop  shown  in  th('  top  of  tlu'  figures  4  Ik'  ojxu’at ions  Toggle  and  Test  are' 
inheuite'd  from  AI_Flipflop  by  AI_Flipf lop_With_Set. 


Java  s  extends  me'eJianism  is  ce)nve'nie'nt  fe)r  encoding  the'  extends  relationship 
be'twf'e'ii  abstraeU  instance's  as  shown  in  higure'  4.0.  }Ie)we've'r.  sine’c  Java  dex's  not 
stip])oi't  template's,  e)nly  the'  abstract  instaiiex'  te)  abstrae*t  instance'  form  e)f  extends 
(eh'fiiH'el  on  ])age'  01)  ma\'  be'  ('iicexh'd  in  Java.  Flirt heianore',  wdif'ii  the'  extends  ke'v- 
w»)rel  is  use'el  to  re'late'  two  Java  classe's.  it  prenJde's  imple'iiu'ntation  inhe'ritane*('  rather 
than  s])f'e4fi(  atieui  inlu'ritaiu'e'.  \\  Idle*  t he  comme)n  mea!dnge)f  the'te'rm  “e'xte'iiels'*  ap- 
plie".  to  both  situations,  we*  ])re'fer  to  classify  the'  use'  of  extends  be'twe'e'ii  two  classes 
a^  a  spe'e-ifie-  ai)i)lie“at ie)n  of  the'  uses  re'lat ie)nship.  While'  im])le'mentatie)n  inlu'ritance' 
i>  use'ful  for  {‘e)ding  couph'd  im])lf'me'ntat ions  e)f  e'xtensiein  comjieinents  as  discussed 
in  Se'e-tie)n  3.3.2,  it  is  alse)  ce)mmonly  use'd  in  situatieins  whe're*  the'rc'  is  ne)  inte'iide'd 
bf'ha\doral  conformanea'  betwf'e'u  the*  compone'iits. 
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//  AI_Flipf lop ,  java 

public  interface  AI_Flipflop  { 
//  modeled  by  BOOLEAN 
//  exemplar  ff 
//  initially  ff  =  FALSE 

public  void  Toggle  (); 

//  ensures  ff  =  NOT  #ff 

public  boolean  Test  (); 

//  ensures  Test  =  ff 

} 


//  AI_Flipf  lop_With__Set  .java 

public  interface  AI_Flipf lop_With_Set 
extends  AI_Flipflop  { 

public  void  Set  ( )  ; 

//  ensures  ff  =  TRUE 

} 


Figure  4.6:  Java  Encoding  of  ALFlipflop_With_Set  extends  ALFlipflop 


Unlike  Java,  most  OOPL’s  use  the  same  inheritance  notation  for  at  least  three 
conceptually  distinct  purposes:  implementation  to  specification  conformance,  speci¬ 
fication  to  specification  conformance,  and  implementation  to  implementation  confor¬ 
mance.  Here  we  are  assuming  that  abstract  classes  are  used  as  specification  compo¬ 
nents.  In  Chapter  5  we  discuss  how  RA95  uses  Ada’s  single  inheritance  mechanism 
for  each  of  these  three  purposes. 

In  addition  to  inheritance,  Ada  also  provides  another  mechanism  which  supports 
extension  of  components  (packages).  Ada’s  hierarchical  library  units  allow  a  “child 
unit”  package  to  extend  an  existing  “parent  unit”  package  without  requiring  any 
alterations  to  the  parent  unit  or  to  systems  which  use  the  parent  unit.  discuss  this 
mechanism  in  detail  in  Chapter  5.)  While  inheritance  is  a  mechanism  for  extending  a 
type,  a  child  unit  extends  an  Ada  package  which  may  include  definitions  of  more  than 
one  type.  Thus,  the  hierarchical  library  unit  mechanism  offers  some  advantages  over 
inheritance  and  is  indeed  quite  useful.  However,  this  mechanism  does  not  support 
substitutability  of  components  as  does  inheritance.  This  is  because  there  is  no  way 
to  encode  the  needs  relationship  based  on  hierarchical  library  units.  That  is,  there 
is  no  way  in  Ada  to  encode  the  requirement  that  any  child  unit  of  a  parent  unit 
may  be  supplied  as  an  actual  parameter  to  a  concrete  template  (a  generic  package) 
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wlu'n  Tlif‘  formal  paiaiiu’tf'r  is  rf\st rictc'd  to  \)v  an  instance'  of  tin'  pan'iit  unit.  Tims, 
the  hif'rarcliical  library  unit  nu'chanisni  alone'  is  not  a])])roi)riate'  for  e'lie-oeling  the' 
implements  re'lat ionshi])  in  a  way  that  sup])orts  e‘oin])e)ne'nt-le've'l  inainte'iiane'e’. 


4.5  Encoding  The  needs  Relationship 

In  Se’(*tif)n  d.  1  wf'  eh'fine'el  the'  needs  re'latie)nship  whieT  is  hase'el  e)n  the'  needs 
re'lation  eh'fine'el  in  Se'ction  2.  1.2.  Tin'  needs  re'lat  ionship  e'X])re'sse's  a  eh'fe'rre'el  eh'])e'n- 
eh'iie'v  on  an  iin])I('in('nt  at  ion  e’e)ni])one'nt .  In  this  se'elion  we'  hrie'flv  discuss  he)W  the' 
needs  re'latie)nshi])  nia\'  he'  e'ne‘e)elf'el  with  prograniuiin^y  lan^yiia.^cs. 

In  promaniininy  lan.^nane'  tf'rins,  usini;  the'  needs  rclat ionshi])  is  a  way  e)f  e'X])re'ss- 
inu  ])oly  morph  ism.  As  disemsse'el  in  Se'ctie)n  1.1  .d,  the'  two  primary  a])])roae*he's  te)  pe)h‘- 
mor])hism  sui)i)orte'el  hy  ])re)t:!;i'amniin,[2,  lan,L!;ua,u;e's  are'  ])arame'trie‘  })e)lyme)ri)hism  anel 
subtype*  (ineTision)  ])e)lyme)rj)hism.  Lan.miage's  sui)i)e)rt  ])arame'trie*  ])e)lyme)ri)hism. 
l)aramr't ('ri/e'd  e‘e)m])e)ne'nt s.  through  ine'eTanisms  such  as  gcne'iie*  ])ae'kagcs  in  Ada. 
ge'ncrie'  classe's  in  hiffe'h  te'm])late's  in  C'-h  +  .  anel  funeiors  in  ML,  Subty])c  ])e)h'me)r- 
])hism  is  su])])ort e'el  by  iidie'rit ane'e'. 

The'  needs  re'lat ie)nshi])  is  a  form  of  what  many  authe)rs  evill  hninuJid  poJjjiDnr- 
CW^T)  .  If  coneacte'  te'm])late'  needs  abstraeU  instanea'  A.  then  the  se't  e)f 
ae“e'{'] )T a bh'  ae’tual  paiauue't e'i‘s  foi”  (  is  bouneh'el  by  A.  A  ieh'iit ifie's  the  se't  e)f  e*on- 
e'le'te'  instanea's  that  may  be'  usf'el  to  instantiate'  C\  .As  se've'ral  authors  ha\'e'  ])e)inte'el 
e)Ut.  boiineh'el  i)e)lymori)hism  is  eliflieadt  toe'xpre'ss  using  subtype'  ])e)lyme)rphism  alone 
(IWO/,  LDGMD.)  .  Although  it  is  pe)ssible'  to  ene‘e)ele'  the'  needs  re'lat ie)nshi])  using 
e)nl\'  subtype'  polymorphism.  e'ne‘e)eling  bouneh'el  ])e)lyme)r])hism  withe)ut  parametrie* 
])olyme )rphism  te'iiels  to  h'ael  to  ve'ry  awkwarel  e’oeh',  Furtherme)i’e,  reh'ing  em  inheri- 
tane-e*  to  ae*hie'\-ing  bouneh'el  ])olyme)r])hism  (as  emrre'iitly  must  be  elone'  in  Java)  e-an 
h'ael  to  e’oeh'  bloat  anel  ])e'rfe)rmane*e'  pe'iialtie's  fe)r  lam-time'  tyj)e'  e’asting  anel  run-time 
tyj)e*  e’he'e’king  [BlAinf)^.  J  lie're'fore',  e)nr  eJe'ai'  ])re'fe'i'e'ne*e'  is  te)  use'  parame'trie*  pe)h'- 
mor])hi>m.  pe'rha])s  in  e’on june*t ion  with  subtyj)e'  polyme)rphism.  te)  e'ne*e)eh'  the'  needs 
re'lat  ionship. 

Se'ction  b..")  eh'se-ribe's  liow  the'  needs  re'latie)nshi])  is  e'ne‘e)eh'el  in  RLSOIA'E/Aelanb 
using  paranu'trie*  ])e)lyme)rj)hism  (Aela  ge'nerie’s)  anel  subty])e  pe)lyme)rphism  (Aela  t\*i)e 
e'Xte'iision ).  A  similar  a])])re)ae’h  base'el  e)n  C’-fT  te'ni])late's  is  nseel  bv  RlkSOIA'E/C’-f-T 
We'iOr  .  With  both  Aela  anel  e'ne-e)eling  the'  needs  relatietnship  is  ne)t  a  trivial 

matte'!'.  Inste'ael  e)f  a  single'  language*  me'e’hanism  te)  e'Xpre'ss  this  relatie)nshii),  sueJi  as 
fae'ilit\'  paranu'te'rs  in  Rk.SOIA  k.  [SW9!])  se'wral  language'  meeJianisms  must  be*  useel 
in  e'e)njuneaiem  with  e'aeL  e)the'r  te)  aeJiie've'  the*  a])])re)ximate'  effee*t .  We  be'lie've*  that 
this  ])e)iiits  out  a  signifie-ant  we'akne'ss  in  eairre'iit  i)re>gramming  languages  inteneh'el  fe)r 
Use*  in  e‘om])onent-baseel  se)ftwai’e'  engine'e'ring. 


KG 


4.6  Chapter  Summary 


In  this  chapter  we  examined  how  the  mechanisms  of  modern  programming  lan¬ 
guages  can  be  used  to  encode  the  component  relationships  defined  in  Chapter  3.  While 
the  importance  of  modularity,  information  hiding,  polymorphism,  and  extendibility 
has  been  understood  for  at  least  25  years,  the  evolution  of  programming  languages 
has  been  slow.  Only  recently  has  the  importance  of  parametric  polymorphism  been 
recognized  outside  of  the  academic  community  and  been  integrated  into  widely  used 
languages  such  as  C-l— 1-.  Nevertheless,  the  most  widely  used  new  language,  Java, 
currently  does  not  support  parametric  polymorphism.  Furthermore,  most  language 
implementations  that  do  support  parametric  polymorphism  generate  independent 
code  for  each  template  instantiation  which  often  leads  to  code  bloat.  As  we  discussed 
in  Section  4.5,  parametric  polymorphism  is  very  useful  for  encoding  the  needs  rela¬ 
tionship. 

On  balance,  the  emergence  of  OOP  as  a  programming  paradigm  has  led  to  better 
language  support  for  developing  component-based  software.  Most  OOPL's  provide 
good  facilities  for  data  abstraction  and  modularity.  Interface-only  components,  such 
as  abstract  classes,  are  useful  for  defining  structural  specification  components  which 
may  be  augmented  with  behavioral  specifications  to  encode  abstract  components. 
While  there  has  been  a  tendency  to  use  inheritance  for  many  disparate  purposes, 
when  used  in  a  disciplined  manner,  inheritance  is  a  useful  tool  for  encoding  relation¬ 
ships  such  as  implements  and  extends.  Several  newer  languages,  such  as  Java  and 
Theta,  provide  distinct  mechanisms  for  expressing  specification  conformance  and  im¬ 
plementation  inheritance.  In  the  case  of  Java,  use  of  the  kej^words  implements  and 
extends  for  these  mechanisms  makes  encoded  relationships  easier  to  identify  and 
understand. 

A  weakness  of  most  OOPL’s  is  the  use  of  a  single  mechanism,  the  class,  for  both 
modularization  and  new  type  definition.  This  strategy  makes  it  difficult  to  define 
more  than  one  extendable  type  within  a  single  component.  OOPL’s  typically  require 
breaking  encapsulation  when  one  type  needs  access  to  another  type’s  representation. 
Thus,  with  OOPL’s,  encoding  the  extends  relationship  is  generally  limited  to  exten¬ 
sion  of  user-defined  types. 

In  order  to  fully  support  expression  of  behavioral  relationships  between  software 
components,  implementation  and  specification  notations  need  to  be  better  integrated 
into  a  single  language.  While  several  research  languages  have  taken  this  approach,  to 
date,  such  languages  have  received  little  attention  outside  of  academia. 
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CHAPTER  5 


BEHAVIORAL  RELATIONSHIPS  IN  RESOLVE/ADA95 


In  this  chapter  we  demonstrate  how  the  behavioral  relationships  described  in 
Chapter  3  may  be  expressed  using  RESOLVE/ Ada95.  We  begin  with  an  introduc¬ 
tion  to  RESOLVE/Ada95.  Then  we  examine  how  the  language  features  of  Ada  are 
used  to  express  abstract,  concrete,  and  template  components,  and  the  behavioral 
relationships  between  them.  We  continue  to  use  the  component  coupling  diagram 
notation  introduced  in  Chapter  3,  to  express  design  time  relationships.  We  also  in¬ 
troduce  a  new  component  instantiation  diagram  notation  that  depicts  integration 
time  relationships,  i.e.,  how  the  components  of  a  particular  system  have  been  com¬ 
posed.  The  chapter  concludes  with  a  discussion  of  the  limitations  of  Ada  with  respect 
to  its  support  for  expression  of  behavioral  component  relationships. 

5.1  RESOLVE/ Ada95 

RESOLVE/Ada95  (RA95)  is  a  discipline  for  software  component  engineering  that 
combines  the  Ada  programming  language  with  the  specification  notation  and  design 
discipline  of  RESOLVE  [SW94,  WOZ91,  Har90].  RESOLVE  is  three  things.  First, 
it  is  a  detailed  framework  for  software  component  engineering.  RESOLVE  is  also  a 
language  which  includes  two  integrated  sub-languages:  a  model-based  formal  spec¬ 
ification  language  and  an  imperative,  sequential,  ,  programming  language.  Finally, 
RESOLVE  is  a  discipline  with  detailed  design  principles  which  guide  software  engi¬ 
neers  in  the  development  of  high  quality  software  components  and  systems. 

RA95  is  a  major  revision  to  the  RESOLVE/Ada  (RA83)  discipline  described  by 
Hollingsworth  [Hol92]  and  based  on  the  original  1983  Ada  language  definition  [Dep83]. 
Both  RA83  and  RA95  apply  the  component  design  principles  and  formal  specification 
notation  of  RESOLVE  to  software  components  implemented  in  Ada.  Unlike  RA83, 
however,  RA95  explicitly  encodes  the  behavioral  relationships  between  components 
using  new  language  mechanisms.  RA95  also  makes  explicit  the  ACTI  view  of  compo¬ 
nents  as  abstract  and  concrete  templates  and  instances  [Edw95,  §3.3].  Furthermore, 
use  of  new  language  mechanisms  makes  most  RA95  components  much  simpler  to 
encode  than  similar  RA83  components. 
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A(\f]  s  sti'oim  support  for  nH)cliiIarit y  utul  ,u,(UH'ri(*itv  liavc^  lonp,  niadc^  it  a  ^oorl  pro- 
^aainininu  laiitriiayc’  for  iniplfMiH'ntiii,L;- ])arai]i(M(Mi/(Hl  conpxiiKMits.  Tlir  lOno  revision 
to  Ada  arldod  sill )st  ant  ial  in^w  sniijxirt  foi*  ohjcHn-oi'iented  ])rogranunine;  (( )( )P).  a  new 
inodf'l  of  moduli'  exti'iision,  and  nion'  ])ow{'rful  gc’iierie  pai'ain('t(U'i/at  ion  nu'elianisms. 
PAO  )  relif's  lH'a\'ily  on  many  of  tli('  ih'w  Ada  lan,^ua,e;(^  meelianisms.  In  sonu'  aspi'ets. 
IiAO  )  is  similar  to  tin'  HI.SOIA  (liC'PP)  diseipliiK'  d(n'('lo|)('d  eoneurrc'ntlv 

l)v  Pdwarils,  WVidi',  and  Zhuiianov  [WeiOT].  For  exam])l(\  hotli  PAno  and  RCPP  rely 
lH'a\uly  on  inlu'rit ancf'  nu'chanisms  to  sui)])ort  exi)ression  of  Ix'liavioral  relationsliips. 
I  Ill'll'  ari'  many  diflrrriu’i's.  liowi'vi'r,  hi'twi'i'ii  HAO.)  and  RCPP  diu'  to  diffi'renec's 
hi'twi'i'ii  Ada  anil  C  -r -y  and  differt'iiei's  in  th('  hasie  ap])i‘()aeli  takc'ii. 

1  1k'  RC  PP  discipline  ri'lif's  li('a\’ily  on  tlu'  us('  of  ])repro(‘(\ss()r  maeros  that  servi' 
to  make  the  *\souree*‘  laiy^uane  of  a])pear  suhstant ially  different  from  that  of 

ty])iea1  C  J  Ilf'  Ix'iH'fits  of  this  approach  incliuh'  makiiye;  tlu'  RESOIA'E  and  ACTI 
per.spf'ciives  more'  ('X])licit.  hidiiyt;  annoyin,*;  C++  syntax,  and  im])rovins  niaintain- 
al)ilit\  hy  reflu(*in,u  soiircf'  redundancy.  J  Ix'  a])])i'oach  to  RADo  (hxrs  not  ref|uir('  the 
ii^c  of  a  prei)roc('ssor.  Imph'mentin.L^  com])on('nts  usiiyi;  tlx'  RAOo  discipline  entails 
codine  flircfuly  in  Ada.  Oix'  Ix'iiefit  of  this  ai)])roach  is  that  RAHo  uses  language 
mcchanisnis  of  Ada  largi'ly  as  tlx'y  wf'ri'  inti'iirh'd  to  Ix'  nsf'd.  d  hf'rf'foi’i'  ('Xplaining 
the  rat  i(  male  for  RAf)o  s  iisi'  of  various  languagf'  mechanisms  is  ('asier.  Anotlx'r  hen- 
('fit  is  that  maintf'iiancf'  of  lEADo  eodi'  is  maint('nan(‘('  of  Ada  eodi'.  Thus,  analysis 
aixl  maintf'iiancf'  tools  availahle  for  .Afla  shfinhl  hf'  flirf'ctly  a])])lif'a1)l('  to  components 
de\'f'l( )])f'fl  using  tlx'  RADo  flisciplini'.  Idnally.  a  possihh'  j)ractical  hf'iiefit  f>f  this  ajv 
proach  is  that  RAnd  may  hi'  niorf'  acf'f'ssihk'  tf)  f'xpf'rif'iicf'd  Afla  programiiH'rs  than 
RC  PP  is  to  f'xpf'rif'iicf'fl  C -1--^  programnu'rs. 

I)esi)itf'  thf'ir  tri'meiiflous  compif'xity.  ix'ithf'r  Afla  nor  C’+-f  provifh's  an  idf'al 
set  (or  suhsf't)  of  languagf'  nif'chanisms  for  su])])f)rting  software'  (*()m])onf'nt  f'nginef'i*- 
ing.  Ihf'  RESOIA'I-;  language,  which  was  fh'sigiif'fl  six'cifically  to  supjxirt  software 
compoiif'iit  ('ngiiif'f'ring,  can  f'xpn'ss  notions  which  an'  f'itlu'i'  im])ossil)l('  fir  extrf'ineh' 
awkward  to  f'xjirf'ss  in  Afla  or  C-f4-.  }Iowf'\'('r.  oix'  ch'ar  afh'antagf'  Afla  and  C’-f4- 
ha\  f'  o\  ('!'  R I-.S(  )IA  is  t  Ix'  awulahility  of  (*omnx'rcially  siippfirtf'fl  compih'rs  on  a  widf' 
\arif't\‘  of  platforms.  Jims,  RADo  aixl  RC’PP  make'  it  f'asif'r  for  software'  e'ngineers  tf) 
ap])l\'  tlif'  Rl.SOIA  I'.  flisci])liix'  in  tlx'  ini])lf'nx'ntat iein  of  seift wai’f'  compfiix'nts. 

I  Ix'  I'f'maining  sf'fUions  of  this  cha])te'r  discuss  many,  hut  ixit  all,  as])ects  of  RAOo. 
We  focus  ox  t Ix' f'Xi)rf'ssion  e)f  Ix'havioral  le'lat ionships  he't we'e'ii  RAOd  compoix'nts.  In 
floine  so.  wf'  df'scrihf'  ix'arly  all  aspi'cts  f)f  ItAnd  that  distinguish  it  from  RA83.  We 
also  point  out  that  tlx'  R  ADo  dis(‘i])linf' ])rf'S('nte'fl  in  sul>sef|Uf'nt  se'ctions  is  only  one  of 
man>‘  jxissihle  strategif*s  for  ai)])lying  tlx'  Rk.SOIA  I*]  elisci])line  te)  Ada.  This  version 
of  RAO  )  attf'mi)ts  to  e'X])Iicitly  e'xprerss  as  many  as])e'cts  of  the'  RESOIAl*]  franu'work 
a<  i)ossil)l(s  to  tlx'  current  immaturity  e)f  Aela  enimpile'rs  supporting  the  1095 

laneiiauf'  fli'finit ion.  \\f'  ha\‘e'  iifit  Ix'f'ii  able'  to  asserss  the*  ])i'af‘t ie‘alit\'  f)f  this  pai'tieadar 
a])proach  on  large*  systf'ins  (alt hough  all  e’eimpoix'iits  slx)wn  in  this  Cha])te'r  do  ce)mi)ile' 
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on  the  current  GNAT  compiler).  As  Ada  compilers  become  more  robust,  the  RA95 
discipline  may  be  revised  to  ensure  it  provides  a  viable  approach  for  building  large 
systems  with  available  Ada  compilers. 


5.2  RESOLVE/ Ada95  Abstract  Components 

In  RA95,  abstract  components  are  either  abstract  kernel  components  or  extensions 
to  other  abstract  components.  This  section  describes  abstract  kernel  components  and, 
in  doing  so,  most  aspects  of  RA95  abstract  components.  Section  5.6  describes  abstract 
components  that  extend  other  abstract  components. 

An  abstract  kernel  component  is  a  specification  that  typically  has  no  dependen¬ 
cies  on  other  specific  components.  We  could  use,  for  example,  an  abstract  kernel 
component  to  specify  the  behavior  of  a  component  that  provides  a  queue  of  integers. 
In  RA95,  this  specification  would  be  based  on  a  mathematical  model  of  a  queue  of 
integers  such  as  a  string  of  integers.  Here  the  phrase  “string  of  integers”  refers  to 
the  mathematical  concept  of  string  defined  by  string  theory  and  the  mathematical 
notion  of  integer.  The  signature  of  a  queue  of  integers  would  be  characterized  by  a 
type  name,  such  as  Integer-Queue,  and  the  signatures  of  primary  operations  on  that 
type  such  as  Enqueue  and  Dequeue.  The  functional  behavior  of  the  integer  queue 
operations  would  be  described  in  terms  of  the  queue’s  mathematical  model.  For  ex¬ 
ample,  the  behavior  of  an  initialization  operation  could  be  described  as  returning  an 
empty  string  of  integers.  The  behavior  of  an  Enqueue  operation  could  be  described 
as  ensuring  that  the  integer  to  be  enqueued  is  placed  at  the  right  end  of  the  string 
of  integers  modeling  the  queue.  While  a  specification  such  as  this  does  depend  on 
mathematical  string  theory  and  the  built-in  Integer  type,  it  does  not  depend  on  any 
other  software  components. 

An  abstract  kernel  component  specifying  a  queue  of  integers  would  be  an  abstract 
instance.  A  more  useful  specification  would  be  an  abstract  template  describing  the 
behavior  of  a  generic  queue.  Such  an  abstract  template  would  be  parameterized  by 
the  type  of  item  to  be  contained  in  instances  of  the  template.  An  abstract  instance 
of  a  queue  abstract  template  might  depend  on  another  specific  component  providing 
the  item  type.  The  queue  abstract  template  itself,  however,  need  not  depend  on  any 
other  specific  component.  In  order  to  support  greater  reusability,  most  RA95  abstract 
kernel  components  are  abstract  templates  as  opposed  to  abstract  instances. 

One  of  the  aspects  of  the  RESOLVE  framework  that  most  distinguishes  it  from 
other  disciplines  is  its  use  of  the  swapping  paradigm.  RESOLVE  uses  swapping 
instead  of  assignment  as  the  primary  method  for  data  movement.  The  use  of  swap¬ 
ping  provides  profound  benefits  and  is  one  of  the  cornerstones  of  the  RESOLVE 
framework[HW91].  The  Swap  operation  simply  exchanges  the  values  (both  the  ab¬ 
stract  and  concrete  values)  of  its  two  operands.  Swap  provides  the  efficiency  of  assign¬ 
ment  implemented  by  copying  a  pointer  (shallow  copying)  while  maintaining  value 
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s('in;uit ics  liki'  }issi<j;nni('iit  ini])l('nu'iit('(l  hy  coin'iiii!,  a  value  (dec'])  copyiii”).  Using 
s\va])[)iim  avoids  tlu'  aliasing  lu-ohlciiis  wliirli  result  from  sliallow  coining  anrl  which 
signifieant ly  complicate  formal  just ificat ion  of  the  implements  relat ionshi])  l)('tw('en 
imph'ment  at  ions  and  specifications.  An  important  insight  on  which  tlu'  RESOIA  E 
framf'woik  capitalizes  is  that  dec'p  copying  is  rarely  needed  when  components  are  rh'- 
siciK'd  to  use  swapping.  K.AOo's  snp|)ort  for  swa])])ing  as  the'  i)iimary  data  moveunent 
o|)('ration  lias  significant  implications  tliat  aflect  tlu'  way  in  which  Ada  is  used  to 
encode  ahstract  kernel  comixuu'iits. 

An  ahstract  kernel  com])on('nt  is  ('iicode'd  as  an  Ada  jiackage'.  usually 

generic,  w  hich  exjiorts  an  (ihslracf  liijtc  and  (ihsimci  primitive  openitiojis  of  the  tyjx'. 
J  he  exported  ahstract  ty])e  is  declared  as  an  (ihstrari  fdfifjed  limiteil  private  ti/pe. 
In  Afla  ahstract  tyjies  are  taippd  ti/pes  from  which  no  ohjects  (variahles)  may  Ix'  de- 
clarcfl.  Ada  tagged  typi's  are  tyjx's  from  which  new  user-defiix'd  tyjies  may  Ix'  dc’iived 
Using  /y//x  e.rtf  iisnm.  a  form  of  inlu'iit ancc'.  Erimiti\'('  o]x'iations  of  a  taggcfl  type'  art' 
those  ojierations  declared  in  tlx*  same  packtigt'  as  the  laggt'd  ty]x'  and  having  at  h'ast 
out'  parameter  of  the  taggt'd  typt'.  In  Ada.  only  primitive  operations  are  inheritt'd 
hy  new  tyjx’s  deri\'ed  from  another  tagged  typt'.  (In  OOP  terminology,  tlie  ('xjiortt'd 
tatret'fl  t\pe  is  a  class  and  the  ])iimiti\'e  ojierations  are  its  member  fanetinas.) 

1  he  tyjie  exiiorted  hy  a  kt'iiH'l  alistract  com])t)n('nt  is  limited  private  which  nx'ans 
that  HssiminifMit  aiul  ('(jiiality  ojxM'at ions  arr  not  antoniatically  clnfiiKul  for  ohjc'cts  of 
iIk'  typn.  Sinuu  HAf)-)  nsf‘s  swaj)  instracl  of  assii^nnH'iit  as  tlu'  ])i’iniary  data  inovn- 
nuniT  o])f'ration.  a  primitive'  assinnuK'nt  ope'ration  is  unnruossary.  In  situations  wlirro 
thu  fl(H‘p  coiiyinu;  functionality  of  assi,<i,nnu'nt  is  lUM'di'd,  it  may  Ix'  addf'd  with  an 
(Wtf'iision  (‘ompoiKMit  as  de'sciilx’d  in  Si'ction  5.0.  \\  hih’  it  would  !)('  te'chnically  pos- 
sihlc  to  sui)]x)rt  dfx'p  copy  assi,i;umcnt  in  all  keumcl  (‘om]x)n('nts.  tlx'  automatically 
elcfiuf'd  ('(juality  is  an  Ada  functiov  atxl  is  not  com])a1  il)l('  with  RADo  as  ('xplaiix'd 
hf'low.  Thus.  RADo  use's  Aela's  limitexl  ])rivate'  type's  to  pre've'iit  auteimatically  dedincel 
a^^imime'ut  and  e'e|uality. 

An  unfortunate'  re'ejuire'me'ut  (A  Aela  fuu(*tions  is  that  tlu'ir  ])aramcte'rs  must  Ix'  "in" 
ninth  .  J  1h'  inte'ut  eif  this  I'e'ejuire'nu'ut  is  to  ensure'  tliat  a  function  im])l('nKUitatie)n  docs 
not  ehanyc  the  \alue's  of  the'  ae-tual  ])aratne'te'i\s  usexl  in  a  fune’tiou  call.  The'  probh'm 
with  thi^  re'f|uire'me'nt  is  that  it  is  both  ove'rly  re'st ricti\'{'  and  large'ly  ine'flcctive'  in 
achievinu  its  inte'ueh'd  ])ur])ose'.  For  ('xainjile',  ceinsieh’r  an  ope'ratiein  to  de'tcrmine'  if 
two  (jUf'Uf's  arc  cejuivah'ut .  i.e'..  wlx'the'r  the'v  re'])rcse'nt  the'  same'  abstrae^t  value'.  An 
im])lcme'nt at  ion  eif  this  eijie'ration  shoiilel  be'  pe'rmitte'el  tei  remen’e'  anel  com])are'  ite'ins 
from  e'ach  eiue'ue'  as  lony  as  it  re'turns  the'  cjucue's  back  te)  tlu'ir  eiriginal  abstrae-t  value's 
be'fore'  comph't inu,  e'xe'e'Utiein.  Aela.  heiwe've'r,  deie's  neit  allow  an  "in’'  meielc  formal 
parame'te'r  to  be'  passe'd  as  an  ae-tual  paranu'te'r  to  ane)the'r  ope'ration  wlu'rc  an  "in  out" 
inn(h  parame'te'r  is  re'e|uire'd.  J  Ix're'fore'.  ()pe'ratie)ns  of  t lie*  cncapsulate'd  re'pre'se'ntatie)n 
t\’pe'  e-anne>t  be'  use'el  to  elisasse'inbh'  tlie'  (jue'iu's  lu  oreh'r  te)  compare'  inelivieliial  Cjue'ue' 
ite'ins.  A  me'thoel  e)f  e-ii'eaimve'Ut iii.c;  this  limitation  we)ulel  be'  te)  re'])re'S('nt  a  com])one'ut‘s 


data  structure  as  a  pointer  (an  Ada  access  type)  to  an  unencapsulated  data  structure. 
This  is  clearly  unacceptable  as  a  general  solution  since  it  precludes  constructing  data 
representations  from  other  encapsulated  types.  Thus,  in  general,  RA95  prohibits  the 
use  of  Ada  functions  since  they  preclude  implementations  that  need  to  directly  or 
indirectly  alter  formal  parameter  values^^. 

In  the  special  case  of  the  equality  function,  a  more  extreme  general  solution  is 
possible.  We  could  require  that  all  types  support  equality  and  thus  make  it  possible  to 
provide  encapsulation  with  non-limited  private  types.  Then  an  implementation  of  an 
equality  operation  could  call  the  equality  operation(s)  of  its  constituent  representation 
type(s).  This  approach  is  unacceptable  from  the  RESOLVE  perspective  since  for  all 
but  simple  types  equality  testing  tends  to  be  very  expensive  and  is  often  unnecessary 
(and  theoretically  uncomputable  for  some  types).  Therefore,  RA95  kernel  components 
only  define  an  equality  operation  (with  an  Ada  procedure)  on  types  for  which  equality 
is  an  essential  operation.  Like  copying  operations,  RA95  equality  testing  operations 
may  be  provided  as  extensions. 

The  RESOLVE  counterpart  to  an  “in”  mode  parameter  is  a  preserves  mode  pa¬ 
rameter.  An  operation  is  permitted  to  change  the  representation  value  of  a  preserves 
mode  parameter  as  long  as  there  is  no  net  change  in  the  abstract  value  of  the  parame¬ 
ter.  In  addition  to  preserves  mode,  RESOLVE  parameter  modes  include  alters  mode, 
produces  mode,  and  consumes  mode.  An  operation  may  change  the  abstract  value  of 
an  alters  mode  parameter.  The  initial  abstract  value  of  a  produces  mode  parameter 
is  irrelevant  to  an  operation’s  effect.  The  initial  value  of  a  consumes  mode  parameter 
generally  is  relevant  to  an  operation’s  effect  and  its  final  returned  value  must  be  an 
initial  value  of  its  type.  In  RA95,  operations  are  encoded  as  procedures.  All  parame¬ 
ters,  regardless  of  the  RESOLVE  mode,  use  Ada’s  “in  out”  mode  except  for  preserves 
mode  parameters  of  built-in  scalar  types.  In  this  situation  “in”  mode  is  used  in  order 
to  allow  scalar  literal  values  as  actual  parameters.  Formal  comments  identify  the 
RESOLVE  mode  of  each  procedure  parameter  in  RA95.  While  RESOLVE’S  parame¬ 
ter  modes  convey  design  intent,  their  primary  purpose  is  to  simplify  specification  of 
operation  preconditions  and  postconditions. 

All  RESOLVE  components  that  define  types  provide  the  three  standard  opera¬ 
tions:  Initialize,  Finalize,  and  Swap.  Initialize  sets  the  abstract  value  of  an 
object  to  an  initial  value  of  its  type.  RESOLVE  guarantees  that  all  objects  are  au¬ 
tomatically  initialized  when  they  come  into  existence.  Finalize  is  typically  used 
to  reclaim  system  resources  allocated  to  an  object.  RESOLVE  guarantees  that  all 
objects  are  automatically  finalized  immediately  before  they  cease  to  exist.  The  func¬ 
tional  behavior  of  Finalize  usually  does  not  need  to  be  specified.  Swap  exchanges 
the  abstract  values  of  two  objects  as  described  above. 

2®RES0LVE/C-I--H  does  not  suffer  from  this  annoyance  since  C-I--I-  function  parameters  may  be 
modified. 
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IiAD  )  uses  A(l;i  s  cniifrollcd  fujx's  to  fu'|ii('v('  aiitoinatic  initialization  and  final¬ 
ization  of  all  ohjocts  (■.\(('i)t  hiiilt-in  scalars.  A  controlled  tyi)e  is  a  tasRod  type' 
de'iived  fidin  eitlu-r  Controlled  or  Limited_Controlled.  two  types  defined  in  tli<' 
l)uilt-in  jeackaye  Ada. Finalization.  Liniited_Controlled  has  two  primitive'  o])- 
e'latioiis:  Initialize  anel  Finalize.  I  lu’se'  eejx'iat ieens  ha\'e'  nnll-heeeh’  iniple'inen- 
tatidiis  wliieli  may  he'  ene'rrielele'ii  as  lU'eTssary  feer  ele'se’enele'iit  type's  de'rive'd  freem 
Liir.ited.Controlled.  While'  the'  e'xaed  details  are  einite  inveelve-d.  Aela  hasie-ally  as- 
snre'.s  that  an  Initialize  ope'iatieen  is  anteematically  e  alle'el  wIk'ii  an  ohje'ct  of  a  con- 
trolle'el  tyj)e'  e'eeme's  intee  e'xist e'lH'e’.  Similarly.  Ada  assnre's  that  a  Finalize  operatieen 
is  ant ( limit ieally  ealle'el  imme'diat e'ly  he'feere'  a  ceintreille'el  ty])('  eihje'ct  ce'ase's  to  e'.xist. 

.•\h>trae't  ke'niel  e'eimiione'iits  de'ri\-e'  their  exiieirte'el  type*  freim  Limited_Controlled 
with  a  mill  n cord  c.rlt  nsimi  in  the'  privaU  part  eif  the'  pae'kaee'.  d  lit'  priwite  dt'rivatiein 
assure',,  that  Initialize  anel  Finalize  canneit  he  ealle'el  e'xplicitly  hy  clients.  The'  mill 
re'corel  e'xte'iision  adels  nti  data  n'lire'se'iitatiein  to  the'  tyjie  himite'dX’ontreille'd  anel  thus 
t'flect i\'e'ly  lear't's  the'  data  le'jire'sent at ieni  eif  the'  <'X])e)rte'el  tyjie'  nnspecifie'el.  (Due'  tei 
Aela  jicce'ssihility  rule's,  the'  derivatiem  freiiii  Limited^Controlled  must  take'  jilace'  in 
the'  ahsiract  ke'ine'l  ceuupone'iit  anel  caniieit  he  jihu'e'tl  in  a  e'euie're'te  comjieineiit.  wdiich 
wuulel  ht'  a  meire'  a])i)rti])riate'  hicatieui.)  In  eirele'r  tei  de'ri\'e'  the'  e'xportt'd  t\'])e'  freuu 
Lir.ited_Controlled ,  the'  ])acka,ti,e  e'liceieliii^  a  ke'niel  ahstract  ceimpeuu'nt  uses  the' 
liiiili-in  pacbiyt'  Ada .  Finalization.  The'  with  rnntr.rt  clitusi-  in  the  (/Inhal  ronfc.rf 
.•xrhnji  tif  ceimiieiuents  expre'.sse's  this  inses  re'latiemshi]).  In  RESOIA'E.  the 

yhihal  ceiiiie'xt  .se'ctioii  lists  all  nein-parame'trie  elejie'nelt'ncie's,  \\e'  eliscuss  the'  uses 
re'laf ieiiishiii  in  lEAfT)  in  Se'e-tion  d.-'h 

In  aelelitiein  tei  the'  implicit  eijie'iat ieuis  Initialize  anel  Finalize  inlu'rite'el  frtiin 
Limited_Controlled.  all  ahst  rae't  ke'i  ne'l  eeimpeuients  explicitly  e'xjteert  Swap  anel  eithe'r 
nhstnicl  nj)f  nit iinis.  An  Aela  ahst  rae't  eijie-rat  ieiii  is  a  jirimit  ive  eijie'e  atieui  that  must  he 
eive'irielele'ii  with  ail  imiile'ine'utat ieui  for  a  neui-ahst rae't  tyjie'  eh'iive'el  freuu  the'  ahstrae-t 
tyi)('.  I  he'  e'xpeu'te'el  ahstrae't  tyjie'  anel  ahstrae't  eipe'ratieuis  ale)n,i>  with  feinnal  spe'e'i- 
fieatieiiis  e'lulie'eleh'el  in  st riie't iire'el  e'eumue'iits  prewieh'  the'  ke'inel  ahstract  e'euiijeeuie'iit's 
simiatiiiT'  jHid  IxdinA'ioral  s])f'('ifi(Tit ion. 

Ahsiraet  ke'rne'l  eeiiuiieuie'iits  are'  ty])ie'ally  ahstrae't  te'm])late's  parameterized  hy 
eithe'i'  eompeine'nts.  J  he'se'  ahstrae  t  te'inplate's  are'  I'lie'eiele'el  in  RAD-”)  as  "e'lie'iie'  ])ae‘k- 
aye's,  d  Ih'  ahstrae't  te'iiijilate'  parame'ters  are'  iue'luele'el  in  a  spccifiaitinn  piiraiiirtrrs 
siciiov  anel  are'  e'lie  eide'el  as  Aela  ye'iie'iie  feirmal  parame'te’is.  Eae'h  eeuuixuie'iit  impeirted 
as  a  spe'e'ificat ieiii  jiarame'te'r  is  ene'eiele'el  as  a  liiiiilid  pririifr  (/ciirric  foriiiiil  li/jir  pa- 
niim  ft  r.  Eae-h  yene'i  ie'  feu  iual  tyjie'  ])arame'te'r  must  have' an  associate'el  (p  iicrir  fornud 
siihpropniiii  paniinrtir  impeu't iny  t he'  Swap  eijie'catieui  feir  that  tyjx'.  Other  yenerie'  feu- 
mal  suh])royrams  may  he'  use'el  tei  jilae'e'  e'euistraints  eui  imjieirte'el  e'onpieuients.  Aela's 
suhproyram  eh'fault  heix  six'eifie-at ieui  (<>)  is  use'el  with  all  ye'ne'iie'  feuinal  suhiuei- 
yiaiiis  tei  sim])lifv  ye'iie'rie'  paekaye'  inst antiat ieui.  \le’  dise'uss  sjie'e'ifie'at ieui  paranu'te'rs 
furthe'i'  in  Se'e  tion  •'i..'). 
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The  name  of  a  kernel  abstract  component  is  the  name  of  the  abstraction  being 
described,  prefixed  with  AT_  or  AI_,  depending  on  whether  it  is  an  abstract  template 
or  an  abstract  instance.  For  example,  AT.Queue  is  the  package  name  of  a  kernel 
abstract  component  describing  a  queue.  The  name  of  the  exported  type  is  usually 
the  name  of  the  abstraction  being  described.  For  example,  the  type  exported  from 
AT-Queue  would  be  named  Queue.  In  some  cases,  the  type  name  may  be  shortened 
to  improve  the  readability  of  the  code.  Note  that  an  abstract  template  only  requires 
a  package  specification  and  no  associated  package  body. 

Figures  5.1  and  5.2  show  the  RA95  code  for  the  AT_Queue  component.  The  only 
aspect  of  this  code  not  described  above  is  the  design  choice  of  which  operations  should 
be  primary  operations  included  in  the  kernel  component.  The  choice  of  primary  oper¬ 
ations  for  AT_Queue  reflects  the  RESOLVE  design  principle  that  a  kernel  component 
should  be  as  simple  as  possible  while  providing  a  client  controllability  and  observabil¬ 
ity  over  the  component’s  abstract  state  [WEH+QG].  While  other  queue  operations  will 
inevitablj^  be  useful  in  various  contexts,  these  secondary  operations  may  be  added  as 
extensions  and  implemented  by  layering  on  top  of  the  primary  operations  provided 
by  the  kernel  component. 

5.3  The  RESOLVE/ Ada95  uses  Relationship 

As  we  have  mentioned  before,  Ada’s  with  clause  is  the  primary  mechanism  for 
encoding  the  uses  relationship  between  two  Ada  packages.  However,  since  one  of  the 
goals  of  the  RESOLVE  discipline  is  to  minimize  fixed  design  dependencies,  the  uses 
relationship  is  employed  quite  sparingly  in  the  design  of  RA95  components.  In  order 
to  minimize  coupling  and  maximize  reusability,  the  RESOLVE  discipline  suggests 
that  components  (abstract  and  concrete)  be  fully  parameterized  [SW94,  pp.  34,40] . 
That  is,  all  dependencies  which  can  be  deferred  should  be  deferred  rather  than  fixed. 
In  terms  of  software  component  relationships,  this  means  that,  whenever  possible, 
components  should  be  designed  with  dependencies  expressed  in  terms  of  the  needs 
relationship  rather  than  the  uses  relationship.  Usually,  a  uses  relationship  between 
two  RA95  components  either  is  associated  with  a  needs,  implements,  or  extends 
relationship  (as  discussed  in  subsequent  sections),  or  is  a  dependency  on  a  component 
in  Ada’s  predefined  language  environment  (a  built-in  package). 

The  abstract  template  AT_Queue  shown  in  Figures  5.1  and  5.2  uses  two  Ada  built- 
in  packages.  The  with  clause  in  the  global  context  section  explicitly  documents  a  fixed 
dependenc}^  on  the  package  Ada. Finalization  as  discussed  in  Section  5.2.  There  is 
also  an  implicit  dependency  on  the  built-in  package  Stemdard  which  defines  all  of 
Ada’s  pre-defined  identifiers,  primarily  those  of  the  built-in  types  and  operations.  In 
this  case,  AT_Queue  requires  visibility  to  the  Standard  package  for  the  definition  of 
the  type  Integer  referenced  in  the  declaration  of  the  Get_Length  procedure.  All 
Ada  packages  have  implicit  visibility  to  Standard.  No  “with  Stemdard”  clause  is 
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“  -  C or.p  or.  or. :: :  /;  j  „ Qu  c  u  a 
P.clat  ior.F :  - 


~  ~  Glo b a  2  Co r.  t  c x 


with  Ada  .  Fir'a:  izatiion; 


generic 


-  -  Sp  cci  f  lea::  i  on  Pa  ramc  t  ors 


type  izcr:  is  limited  private; 

with  procedure  Sv;ap  (left,  right  :  in  out  Item)  is  <>; 


package  A._Qucue  is 


rcrrace 


type  Qucjo  is  abstract  tagged  limited  private; 

-~I  type  Quc'jc  is  modeled  by  string  of  Item 
exemplar  q 

initial ization  ensures 
'  a  =  emp ty_ string 


procedure  rr.gucue  ( 

c  :  in  out  Queue;  --/  alters  q 

X  :  in  out  Item  consumes  x 

)  is  abstract; 

— !  en s u re s 

q  ~  Pq  *  <Px> 


l  isurc  •■).]:  S])('(  ificat  ion  for  AT-CJik'uo 


11.^ 


procedure  Dequeue  ( 

q  :  in  out  Queue; 
X  :  in  out  Item 
)  is  abstract; 

--!  requires 

--!  q  /=  empty_string 

ensures 

--!  #q  =  <x>  ^  q 


procedure  Get_Length  ( 

q  :  in  out  Queue; 

length  :  in  out  Integer 

)  is  abstract; 

--I  ensures 

--/  length  =  Iql 


procedure  Swap  { 

left  :  in  out  Queue; 
right  :  in  out  Queue 

)  is  abstract; 

ensures 

--!  left  =  bright  and  right  =  #left 


private 

type  Queue  is  abstract  new  Ada . Finalization . Limited_Controlled 

with  null  record; 


end  AT_Queue; 


Figure  5.2:  Package  Specification  for  AT -Queue  (Continued) 


--1  alters  left 
alters  right 


--/  preserves  q 
--1  produces  length 


--!  alters  q 
produces  x 
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iic(r><;uy.  In  CCD's.  \v('  flo  not  depict  uses  reUit ionsliiixs  involving  tlie  Standard  and 
Ada  .Finalization  ])acka,u:('s. 

I  nlike  Hk.SOIA  k,.  Ada  does  not  pnnidc'  a  swap  ojx'ration  for  biiili-in  types. 
In  order  for  a  hiiill-in  tyjx'  to  ser\('  as  tin  actual  packa,u;e  |)ar;iniet('r  in  compo¬ 
nent  coinposition.  the  Swap  ])roeediir('  must  Ix'  availtihh'.  The  s])ecial  RAO.')  pack- 
attc'  CI_Scalar_Operations  provides  Swap  procedures  for  tlu'  Ada  built-in  types: 
Boolean.  Integer,  Character,  and  Float.  This  package  also  provides  (in  juocedure 
form)  commonly  usi'd  opertitions  for  copying,  erjutdity  testing,  and  onh'r  testing.  As 
di-'Cii'^scd  in  Si'ction  .").2.  Atla  functions  with  in-mode  only  i)aramet('rs  ])r('sent  serious 
prolilems  for  comi)on('nt  composition  in  R.VO.').  We  discuss  a  related  issue,  automatic 
initiali/ation  of  built-in  sctdars.  in  Section  .o.O. 


5.4  The  RESOLVE/Ada95  implements  Relationship 

In  R.\0.).  concrete  componc'iits  tire  eitlu'r  roiiciy  fc  cotvpoucul s  or  imple- 

menttitions  of  abstract  extension  com]X)nents.  I'his  section  (h'scrilx's  concrete  ki'rnel 
components  and  ('X])re.ssion  of  tlx'  implements  relationship  bi'twixm  concreti'  and  ab¬ 
stract  kernel  conipoiK'iit s.  Si'ction  .'>.0  deserilx's  concri'te  compoiK'iits  that  iniph'iiu'nt 
flhslITlct  OXTfTlsion  COinpoiHMltS. 

HAD.)  coiicrotf'  b'riH'l  (•()nii)()nriits.  iniphTiu'iRations  of  abstract  krnirl  conipo- 
iuTit>.  arc*  (TicoflfTl  in  Ada  as  r/r/zc/v’c  child  innf  pdk'kkujrs,  A  concrc'ti'  k(MTud  coin- 
poiHTit  is  a  ^riKM'ic  cliild  unit  of  tlu'  al)Straf't  kcTTicl  (’onipoiHTit  that  it  ini])l{Tnrnts. 
A^  di-'cussf'fl  in  ScTiions  3.3  and  •1.3.  a  sin,L;i('  concrc'tf'  ('oni]>on('nt  may  imjdfMiKTit 
nioi'f’  than  oiu'  abstract  con)])on(Tit ,  In  RAOo.  lunvfn't'r,  (vicli  iniphuiuTitation  is  pcr- 
inaiuMitly  linkcnl  to  a  sin,i;l(’  s])('cifi(*at ion  that  it  iiiijihuiuTits.  lliiis.  an  implements 
rclation^hi])  is  (TH'odf'd  dir('ct  ly  into  (TK‘h  concrcdc' component  in  RADo.  Limiting  each 
concif'tf'  tem])latf'  to  a  single'  implements  n'lationsliip  sacrifices  litth'  in  practice  and 
ri'siilts  in  simph'r  RADb  code'. 

Cliild  units  are'  a  part  e)f  the'  hi(d'(}rchir(il  Uhnirii  structure'  aelde'd  to  Ada  in  tlie 
1003  lantmage'  de'finit ieui.  A  e*hild  unit  is  an  Aela  package  that  has  full  visibility  to 
the'  i)ackage  si)e'cificat ie)n  of  aiieithe'r  unit,  its  parent  unit.  Sine-e  a  chilel  unit  niav 
bf'  the'  pare'iit  unit  tei  eithe'r  child  units,  a  hie'rarchy  e)f  re'late'd  librar\'  units  may  be' 
e-(»nstriicte‘d.  Idnis.  a  eLild  unit  uses  its  ])are'nt  unit  as  we'll  as  any  otlu'r  units  above 
it  in  the*  hie'i’areLy  (e'.g..  its  pare'iit  unit  s  jiare'iit  unit).  The'  associatiein  of  a  chilel  unit 
l(»  its  pare'iit  is  e'ncoele'el  by  the'  pae-kage'  name'  of  the'  eLilel  unit.  A  cliild  unit  package' 
name'  has  as  a  pre'fix  its  pare'iit  unit's  pae'kage'  name'  followe'd  by  a  pe'rioel.  Tims, 
the'  packaue'  AT_Queue . CT_2  is  a  eTilel  unit  e)f  the'  jiaeTage'  AT_Queue.  As  a  cliild  unit. 
AT.Queue .  CT_2  has  implieat  \‘isibility  te)  all  of  the'  AT_Queue  ])ae*kage'  spe'eaficatiein. 
iiie’huliim  ge'iieric  formal  paranie'te'rs  ane!  the'  pri\'ate'  jiart.  A  (*hild  unit  eloe's  not  lU'ed 
a  with  clause'  for  visibility  tei  its  pare'iit  unit. 


AT  Queue 


I 


1 


implements 


ATjQueue.CT  2 


Figure  5.3:  The  implements  Relationship  in  RA95 


RA95  concrete  component  names  encode  (the  claim  of)  an  implements  relation¬ 
ship.  The  package  name  AT.Queue  .CT_2,  for  example,  identifies  the  “second”  concrete 
template  that  implements  the  queue  abstract  template.  (The  name  is  best  inter¬ 
preted  from  right  to  left.)  By  RA95  convention,  numbers  are  used  to  distinguish 
concrete  templates  which  serve  as  multiple  implementations  of  the  same  abstract 
component.  Use  of  this  convention  helps  avoid  long  and  possibly  misleading  compo¬ 
nent  names.  Figure  5.3  shows  the  component  coupling  diagram  depicting  the  imple¬ 
ments  relationship  between  concrete  template  AT_Queue .  CT_2  and  abstract  template 
AT -Queue. 

Recall  from  Chapter  3  that  a  CCD  depicts  design  dependencies  that  are  inde¬ 
pendent  of  any  particular  use  of  the  components  involved.  In  contrast,  a  component 
instantiation  diagram  (CID)  shows  how  the  components  in  a  particular  system  are 
coupled  with  each  other.  Figure  5.4  shows  the  RA95-specific  component  instantiation 
diagram  depicting  the  parent-child  relationship  between  abstract  and  concrete  kernel 
components.  Note  that  this  parent-child  relationship  is  not  a  component  relationship; 
it  is  merely  one  possible  technique  useful  for  expressing  the  implements  relationship 
in  Ada.  In  this  example,  the  abstract  parent  unit  AT_Queue  is  enclosed  in  the  concrete 
child  unit  AT -Queue  .CT_2.  This  notation  conveys  the  idea  that  the  definition  of  the 
child  unit  “includes”  that  of  the  parent  unit. 

CID’s,  like  CCD’s,  depict  abstract  components  with  clear  rounded  boxes  and 
concrete  components  with  shaded  rectangular  boxes.  Specification  parameters  are 
shown  as  arrowheads  along  the  top  of  abstract  components.  In  Figure  5.4,  Item 
is  the  only  specification  parameter  shown.  The  generic  subprogram  parameter  for 
Swap  for  type  Item  is  implied  since  all  RESOLVE  types  provide  Swap.  The  type 
exported  from  a  component  is  shown  as  an  arrowhead  on  the  right  side  of  the  box. 
Implementation  parameters  (discussed  later  in  this  section)  are  shown  as  arrowheads 
along  the  bottom  of  concrete  components.  A  more  detailed  version  of  this  notation 
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^  Item  "S. 

Queue' 

AT  Queue 


T 


AT_Queue.CT_2 

_ _ ^  AT  One  Way  List 


I  i,L;;nr(‘  .>.4:  Concrrtc'  Child  C’()U])l('d  ](>  Ahstiact  PanMit 


(not  shown  1  iiK*lii(l(\s  th('  naiiins  of  (\u*h  ('xporU'd  ()])(n'at ion  in  thc^  hmpr  rii2,ht  cornor 
of  thf'  l)ox.  C  ID  s  in  snl)S('C|iKnit  s(H*tions  will  hnild  upon  this  diau;rain. 

All  MAD.')  coiHTf'tc  k('ni('l  conipoiK'iit  ('xports  n  coiicn'tc  type  and  concn'tc'  i)riini- 
li\f’  ()] )f’i a t ions  of  that  ty])(’.  1  1h’  concic'lc  tyjx'  ('X])ort(’(l  is  a  jinvafc  ti/pc  (wtciisioii 
of  tho  atisirart  ry])C'  fxporli'd  hy  its  iiaivnt  nnit.  Tlio  tyjx'  ('xtrnsion  forms  an  inlu'ii- 
taix’i'  link  Ix'twfx'ii  the  com  ri'ti'  and  aiistract  type's.  Tliis  link  is  d('j)ict('d  in  Fi'j,iir('  a. 4 
a',  the  line  connect  in, y  the  ahstract  type  expexted  frotn  AT.Queue  (AT_Queue  .  Queue) 
to  the  concrete'  tyjie'  e'xieex  t e'el  frenn  AT.Queue  . CT_2  (AT.Queue . CT_2 . Queue).  This 
inherit anee'  link  re'fiuire's  the'  e'hilel  unit  iniple'inentat ieen  tei  preevieli'  ceene're’te  ])rimi- 
tive  ei])e'rations  earn  form  iii.y  (st  rnel  nrally)  to  the'  ahstrae't  ty])e‘s  ahstrae-t  primitive 
eipe'iat ions.  1  Ix're’fore’.  an  .Aela  e'ompile'r  will  e'listire'  that  a  ceeneu'ete'  e'exnpeuu'nt  at 
le-a-t  provieh's  the-  strm  tural  interfaea'  ele'serilxal  hy  the-  ahstrae’t  ea)mi)onent  that  it 
implenie'nts.  Of  eamrse.  Aela  ea)m])ile'rs  proviele  no  lii'l])  in  e'lie'ckin,';  wlx'tlier  a  con- 
eie'ti'  eexnpexK'iit  ae  tiially  proxieh's  the'  he'havie)!’  sjie’e’ilie'el  hy  an  tthstrae’t  (aeinjinne'iit . 
The'  formal  se'inantie's.  proeif  rule's,  anel  .s]x'i  ifie'ation  suhdangna.ee  eif  the'  RESOIA'E 
lamruace'  elo  preivieh'  suiipext  for  feermally  ve'rifviu'’  the'  implements  re'latiexiship. 
t  houuh. 

I  nlike  ahstrae't  eeuniiexients.  e'exie'ie'te  eeunieeeuents  reejtiire'  both  a  pae'kage  spe'e-- 
ilie  ation  atul  a  ])ae'kage'  hoely,  7  he'  pae'ka.ge’  s])e’e'ifie'atie)n  iue'luele's  a  ])uhlie'  inferfarr 
ill  uhieli  the'  e'xjieirte'el  type’  is  de’iixa'el  freun  the'  ahstrae't  t\pe’  e'xporte'el  hy 
the  jiate’iit  unit,  Plaeing  this  tyjie'  ele'iix'at ion  in  the'  puhlie'  se’e'tiem  preivieh's  a  jxiiiial 
I  ii  II'  of  the'  e'xpeu'te'el  type'.  J  he'  jitirtial  vie'W  jireiviele's  a  e’lie'iit  e)f  the'  imple'ine'iita- 
tion  x'iaihility  tei  the'  e'xpeirte'el  e’euieie'te'  e)|)e'ratie)ns.  hut  met  te)  the'  t\pe' s  ])ri\ate'  elata 
le'jue'se'ntatieiii,  I  Ix'  inte'ifae'e'  se'e’tieui  alsei  ine  liiele's  a  ceiiu're'te'  suh|)re)”ram  Ix'tide'r  e'eu- 
re'sponeling  tei  e'ae-h  ahstrae't  eijeeratieui  in  the'  |);ire'nt  unit.  The'  j)ae'kage  body  ine'luele's 
all  e.f  the'  eaM're'spemelin.g  suhpreigratu  heielie's.  77ie  pae’ka.ge  heiely  also  may  include'  a 
Inciil  (ijjf  nifinns  se'e’tiexi  feir  leie’td  (private')  suh])re)gratns  iiseal  inte'rnally  to  im])lement 
the'  e'Xpeuteal  e)]X'rat  ieuis. 


The  private  part  of  the  package  specification  includes  a  representation  section 
and  an  implicit  operations  section.  The  representation  section  defines  the  data  struc¬ 
ture  used  to  maintain  state  information  for  each  object  declared  from  the  concrete 
component.  The  full  view  of  the  exported  type  is  a  single  field  record  extension  of 
the  abstract  type  in  the  parent  unit.  To  ensure  composability  of  components,  the 
single-record  extension  field  is  always  named  rep.  The  type  of  the  rep  field  is  the 
type  of  the  component’s  data  representation.  If  the  representation  has  more  than  one 
constituent  component,  the  components  are  encapsulated  in  a  single  RA95  Recordn 
component  which  serves  as  the  type  of  rep.  Recordn  components  are  special  RA95 
components  that  export  Swap  and  field  selection  operations.  Recordn  components 
compose  with  other  RA95  components  and  are  responsible  for  encapsulating  vari¬ 
ous  memory  management  strategies.  Formal  comments  in  the  representation  section 
describe  the  implementation’s  convention  and  correspondence.  The  convention  spec¬ 
ifies  any  representation  invariants  and  the  correspondence  describes  the  abstraction 
relation,  a  mapping  between  the  representation  states  and  the  model  states. 

The  implicit  operations  section  is  where  the  inherited  Initialize  and  Finalize 
operations  may  be  overridden,  if  necessary.  The  exported  concrete  type  inherits  con¬ 
crete  null-bodied  implementations  of  these  operations  from  its  abstract  parent  (which 
inherits  them  from  Limited-Controlled).  For  typical  components,  the  inherited 
Initialize  and  Finalize  provide  the  correct  behavior.  However,  some  components 
will  need  to  explicitly  override  these  operations,  especially  Initialize. 

Since  a  concrete  kernel  component  is  a  child  unit  of  an  abstract  kernel  compo¬ 
nent,  it  has  direct  visibility  to  any  specification  parameters.  Thus,  the  specification 
parameters  are  implicit  parameters  to  the  concrete  kernel  component.  This  idea  is 
conveyed  in  Figure  5.4  since  the  specification  parameter  Item  on  the  top  edge  of 
AT -Queue  is  also  on  the  top  edge  of  AT-Queue  .CT-2.  In  addition  to  implicit  specifica¬ 
tion  parameters,  a  concrete  component  also  may  have  additional  parameters  which, 
if  present,  are  included  in  the  implementation  parameters  section.  Implementation 
parameters  are  encoded  in  RA95  as  generic  formal  packages,  types,  and  subprograms 
for  which  actual  parameters  must  be  supplied  through  instantiation.  We  discuss  how 
implementation  parameters  are  used  to  encode  the  needs  relationship  in  Section  5.5. 

Figures  5.5  and  5.6  show  the  package  specification  for  the  concrete  template 
AT -Queue .  CT_2  which  implements  AT-Queue  shown  in  Figure  5.1.  Figures  5.7  and  5.8 
show  the  package  body  for  AT-Queue .  CT_2.  These  may  be  compared  with  the  similar 
concrete  template  implementing  a  stack  shown  in  Figure  3.11.  We  discuss  the  needs 
relationship  encoded  by  this  component  in  the  next  section. 

5.5  The  RESOLVE/ Ada95  needs  Relationship 

As  we  discussed  in  Section  5.3,  a  fixed  dependency  on  an  Ada  program  unit 
is  encoded  in  RA95  by  a  with  clause  in  the  global  context  section.  For  example. 
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--  Ccr.poncr.t : 
--  Relations: 

Corr-ents : 

AT_Oucuo .  CT_2 

irplcn.cnts  AT_Qucuc ,  needs  AT_One_Way_Llst: 

queue  implemented  with  a  One_Way_List  representation 

--  Global  Cor. 

with  A7__0:'.c_v; 

av’  List ' 

generic 


--  Ir.plcr.cntat:  ion  Paramctcirs  - 

with  package  AI_Ono„V:ay_List  is  new  AT_Onc__Way_List  (Iten^.  =>  Iter.)  ; 
type  List  is  new  AI„Ono„Way_List . List  with  private; 


package  AT_Qucjc . C7_2  is 


--  ir.tcrfacc 


type  Qacuo  is  new  AT_Qucuc . Queue  with  private; 


procedure  Enqueue  ( 

q  :  in  out  Queue; 
X  :  in  out  I  ten 


procedure 

q 


)  ; 


>: 


Dequeue  ( 

:  in  out  Queue; 
:  in  out  I  ten. 


I  i,u,ur('  r)..");  PacK-M,”('  S])('cificati()ii  for  .■\T.(,)ii('ii('.C‘T_2 
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procedure  Get_Length  ( 

q  :  in  out  Queue; 

length  :  in  out  Integer 


procedure  Swap  ( 

left  :  in  out  Queue; 
right  :  in  out  Queue 


private 


--  Representation 


type  Queue  is  new  AT_Queue . Queue  with 
record 

rep  :  List; 

end  record; 

-- !  conven tion 
true 

correspondence 

--!  g  =  q. rep. left  *  q. rep. right 


--  Implicit  Operations 


--  Inherited  null-bodied  Initialize  and  Finalize 


end  AT_Queue . CT_2 ; 


Figure  5.6:  Package  Specification  for  AT_Queue.CT_2  (Continued) 
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-  -  C or.p or. or.  t :  A7_QuCiic  .  CT_2 

--  RclatiorF :  irpl  events  AT_Quciic,  needo  AT_Onc_Way_List 

Corr'.cr.tF :  qjc'jc  iiriplcmcntcd  v/ith  a  Onc_Way__List  r'cprcscntat ion 


--  Globa]  Context 


package  body  A7_Qucuo . CT_2  is 


-  -  I.rp licit  Ope 2.‘'at  ions 


--  Inner! ted  nail -bodied  Initialize  and  Finalize 


-  -  i.rterface  Opera  t  i on s 


procedure  Enqueue  { 

c  :  in  out  Queue; 

X  :  in  out  ItciTi 

)  is 
begin 

Kovc_To_Finish  (q.rep) ; 
Ad  d_R i g h  t  { q . r  c  p ,  x )  ; 
end  Enqueue; 


procedure  Dequeue  { 

q  :  in  out  Queue; 

X  :  in  out  iten- 

)  is 
begin 

:-:eve_7o_Suart:  (q.rcp); 
Rer:-.Dve_Right  (q.rcp,  x)  ; 
end  Dequeue; 


0.7:  Body  for  Al'_(dn(Mi(\C’T_2 
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procedure  Get_Length  ( 

q  :  in  out  Queue; 

length  :  in  out  Integer 

)  is 
begin 

Move_To_Start  (q.rep) ; 
Get_Right_Length  (q.rep,  length) ; 
end  Get_Length; 


procedure  Swap  ( 

left  :  in  out  Queue; 
right  :  in  out  Queue 

)  is 
begin 

Swap  (left. rep,  right. rep); 
end  Swap; 


end  AT_Queue . CT_2 ; 


Figure  5.8:  Package  Body  for  AT_Queue.CT.2  (Continued) 


dependencies  on  standard  Ada  library  units  such  as  Text_I0  (which  defines  standard 
input  and  output  routines)  must  be  encoded  as  fixed  dependencies.  Even  so,  many 
of  Ada’s  standard  library  units  are  generic  units  or  units  exporting  abstract  types 
(such  as  Ada. Finalization  used  by  AT_Queue  in  Figure  5.1)  and  thus  are  structural 
specifications  of  many  possible  implementations. 

The  needs  relationship  expresses  a  deferred  dependency  -  dependence  on  a  spec¬ 
ification  of  behavior  rather  than  on  a  specific  implementation  of  behavior.  In  RA95, 
as  in  RESOLVE,  the  needs  relationship  is  encoded  using  parameterized  components. 
However,  RA95  uses  Ada’s  type  extension  (inheritance)  to  constrain  concrete  compo¬ 
nents  serving  as  actual  parameters  to  be  implementations  of  the  appropriate  abstract 
component.  This  approach  was  not  possible  in  RA83  which  used  (potentially  long) 
lists  of  generic  formal  subprogram  parameters  to  constrain  type  parameters  [Hol92]. 
Nevertheless,  encoding  the  needs  relationship  in  RA95  is  somewhat  complex  as  it 
makes  use  of  a  combination  of  several  of  Ada’s  more  advanced  language  mechanisms. 

The  uses  relationship  between  a  concrete  template  and  an  abstract  component  is 
encoded  in  RA95  using  a  pair  of  related  generic  formal  parameters  and  a  with  clause 
in  the  global  context  section.  The  with  clause  names  the  abstract  component  upon 
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whifii  tli(’  ini])l('inf'iit;Ui()ii  cl('i)fni(ls.  Thv  first  gc'iioric  i)araniot(M'  is  a  (jdui'U'  foiinnJ 
pfjf'l'dflf  pariUDfif  r  aiul  th('  scv-oncl  is  a  (j('nrrir  forinaJ  (l('rirr(l  ////^r .  Both  of  tlioso 
U('iif'ric  paraiiiotrrs  an'  now  lan,t;iia.t3,('  iiu'cliaiiisnis  achlc'd  to  Ada  in  tin'  lOHo  lansuagr 
dofinitioii.  ]  lio  art iial  parann'tc'r  corn's] )onding  to  tlu'  formal  package  ])araiii('tcr  must 
he  an  instaiicf'  of  the'  abstract  package  com])on(Mit  Ix'ing  used.  Th('  actual  parameter 
corre>p()iKliue;  to  tlu'  formal  d('riv('d  must  Ix'  a  taggc'd  tyj)e  (h'rived  from  the 

al)>trart  ty])f'  ('X])ortf'd  hy  tlx'  first  actual  j)aram('t('r.  Togc'ther.  tlx'se  two  ])arameters 
f'u>ur('  that  tlx'  im])ort('d  type'  has  all  of  the  primitive'  operations  s])ecifi('d  in  the 
ahstinct  i)ar‘kaf!('.  I  Ix're'fore'.  tlx'  imi)orted  coucn'tc'  tyjx'  is  constrained  to  hav('  Ix'en 
('xportf'fl  from  a  conen'te  com])on('nt  which  implements  tlu'  abstract  (*omi)onent 
bc'inu  nsf'rl.  Of  conrs(',  only  tlx'  sti'uctural  asi)ects  of  th('  implements  n'lationshi]) 
are  clx'cked  by  t Ix'  coni])il('r. 

r'ignre'  o.D  shows  a  CX’D  (h'])icting  tlx'  uses  n'lationsliip  betwe'f'ii  the  coix-rete 
tem])!ate'  AT_Queue . CT_2  aixl  tlx'  abstrad  te'inplatr'  AT_One_Way_List.  Tlx'  CT_2  im- 
l)h‘nx'nt ation  of  AT_Queue  use's  a  One„Way_List  as  its  re'pre\se'ntation  as  shown  in 
Fi^jiire's  One_Way_List  is  a  list  abstraction  that  snppe)rts  list  tra\'e'rsal  in  e)ne 

eiire'ction  (thus  allowing  singlv-linke'd  list  impleme'iitations).  It  is  moeh'h'd  by  a  pair  of 
strines  which  e*once'])tnally  repre'sent  the'  left  atxl  right  parts  e)f  the  list.  Traversing  the 
li>t  from  h'ft  to  right  is  nx)fle'le‘d  by  mewing  tlx'  h'ftmost  ite'in  in  the  right  string  to  the 
riuhtmost  ite'in  in  tlx'  le'ft  string.  Thus,  the'  current  j)ositie)n  within  a  One_Way_List 
ma>-  ])('  \'if'W('d  as  Just  to  the'  le'ft  e)f  the'  le'ftme)St  ite'in  in  the'  right  string. 

AT_One„V/ay_List  s}x'cifie's  the'  following  eipe'rations: 

•  Advance  iiuwe's  tlx'  eairrent  ])osition  eiix'  item  te)  the'  right, 

•  Move_To_Finish  nxwes  the  eairre'iit  position  to  the  right  eif  the'  rightmost  ite'm, 

•  Move_To_Start  nxwe's  tlx'  e’lirre'iit  ])e)sitie)n  te)  tlx'  le'ft  e)f  the'  h'ftmost  item, 

•  Add.Right  inse'rts  an  ite'in  at  the'  h'ft  ('ix!  of  the'  right  string. 

•  Remove_Right  re'inove's  tlx'  ite*m  at  the'  h'ft  enel  of  the'  right  string. 

•  Get_Left_Length  returns  tlx'  h'ligth  of  the'  h'ft  string,  anel 

•  Get_Right„Length  returns  the'  h'ligth  e)f  the'  right  string. 

figure's  8  eh'inonstrate'  how  tlx'  needs  re'lat  ionshiji  eh'])ie*teel  in  Figure  5.9  is 
e'ncorh'cl  in  H.\9.}.  1  Ix'  with  eiause'  in  the'  global  ceinte'xt  se'ctie)n  (f  igure  5.5)  ex])resses 
tlx‘  fixe'fl  eh'i)eixh'ncv  of  AT.Queue .  CT_2  on  the  specifie^atieui  AT_One^Way_List.  The 
fii>t  ge'iif'ric  jiaramete'r  in  tlx'  inii)h'm('ntation  jiaramete'rs  se'ctie)n  is  the'  feirmal  ])ae‘kag(' 
AI_One„V/ay_List.  1  Ix'  actual  ])aramete'r  e-eirre'speineling  te)  this  fe)rmal  must  be  a 
parkaee'  which  is  an  instaix'e'  e)f  AT_One-Way_List.  hurt he'rme)re'.  this  instane*e  must 
ha\‘e  be'e'u  inst ant iat e'd  with  tlx'  same'  Item  tyjx'  as  the'  instane-e  of  AT_Queue  which 


Figure  5.9:  The  needs  Relationship  in  RA95 


serves  as  the  parent  of  an  instance  of  AT_Queue.CT_2.  References  to  AT.Queue  within 
AT -Queue .  CT_2  refer  to  the  instantiation  of  AT.Queue  that  serves  as  the  parent  unit 
of  the  instantiation  of  AT_Queue  .CT_2. 

The  second  generic  parameter  is  the  formal  derived  type  List.  The  actual  pa¬ 
rameter  corresponding  to  List  must  be  a  concrete  type  derived  (possibly  indirectly) 
from  the  abstract  List  type  exported  by  the  package  serving  as  the  actual  param¬ 
eter  to  AI_One_Way_List.  Note  that  in  a  component  instantiation  diagram,  a  single 
implementation  parameter  corresponds  to  the  pair  of  generic  parameters  required  to 
express  the  needs  relationship.  For  example,  in  Figure  5.4,  the  single  implementation 
parameter  AT_One_Way_List  expresses  the  needs  relationship  just  described. 

At  the  programming  language  level,  this  encoding  of  needs  assures  that  the  im¬ 
ported  List  type  comes  with  implementations  for  all  of  the  operations  specified 
in  AT_One_Way_List.  In  terms  of  component  relationships,  this  strategy  encodes 
AT -Queue  .CT_2’s  dependency  on  the  behavior  specified  by  AT_One_Way_List  without 
making  AT_Queue .  CT-2  dependent  on  a  specific  implementation  of  AT_One_Way_List. 
In  Sections  5.7.1  and  5.8  we  present  examples  of  how  RA95  components  may  be 
composed  through  instantiation  of  concrete  templates. 

5.6  The  RESOLVE/ Ada95  extends  Relationship 

In  this  section,  we  first  discuss  how  the  extends  relationship  is  encoded  between 
two  abstract  components  in  RA95.  Then,  we  discuss  how  a  layered  implementation 
of  an  abstract  extension  component  is  encoded.  We  present  example  RA95  code  for 
both  types  of  components. 

5.6.1  Abstract  Extension  Components 

The  RESOLVE  discipline  encourages  careful  design  of  kernel  components  with  a 
minimally  sufficient  set  of  primary  operations.  New  functionality  is  then  added  — 
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iiMKilly  OIK'  ojK'nition  ;it  ;i  tiiiK'  with  coiiipoiu'nts  which  cxtciid  the  behavior  of 
('xi>fiim  coiniioiK'nts.  The  ideal  elioiei'  of  ])riinarv  oiierat  ions  for  a  ki'iiiel  coiniionent 
is  seldom  ol)\ions.  One  jiossihle  ai)|)roarh  is  to  (h'siyn  keriK’l  coinjioiK'iits  with  no  o])- 
eraiions  (jnst  an  exported  type),  and  then  to  add  all  operations  as  exti-nsions.  This 
ai)proaeh  is  Ix'iny  nsi'd  with  HI;S0IAT:/C'++  [WeiO?].  TIk'  RESOIA'E/AdaOo  disci¬ 
pline  currently  takes  the  more  convc’iit ional  ap])roach  of  inclndinc;  primarv  ojierations 
with  the  kernel  com])onent,  tis  (h'serihed  in  Sc'ction  5.2. 

I  he  extends  relationshi])  (h'.scrihes  tlu'  Ix'havioial  ri’lat ionshi])  hctwci'ii  two  ah- 
stiact  compf)nents  as  discussed  in  Section  3.5. L  Encoding  tin'  extends  rc’lationshi]) 
iisinc  the  lanyna.ye  mechanisms  of  Ada  pn'sents  some  chalh'iigc's.  Diflicnltii's  arisi'  pri- 
niarilv  from  iif'erliny  to  rc'ly  on  Ad;t  s  single  inheritance  mechanism,  tvjx*  ('xtc'iisiom 
OiK'  of  the  diflicnlties  encountered  when  atti'iiiptiny  to  encode  comixinent  relation¬ 
ships  in  .Ada  imohes  the  ('X])re.s.sion  of  multiple  r('lationshi])s  for  a  sin.L!,ie  component. 
Ada  does  not  din'ctly  suiiport  mnitiph'  inheritance,  which  has  jiroven  useful  in  RE- 
SOLA  f./C  — and  does  not  distiny;ni.sh  hetwei'ii  sjx'cification  inlx'ritance  (structural 
interface'  conformance)  and  imph'mentat ion  inheritance,  as  do  newc'r  OOPL's.  such 

H  .1  rl  \  f  i  . 

R.AD.)  use's  tiiirni  iiilicrU/nirc  tee  ('xpre'.ss  multiple'  de'penele'iicie's  [Intr)5a.  f{-l.G.2l. 
Mixiu  inhe'ritanef'  is  expre'sse'el  iu  .Ada  hy  de'rivinji,  an  ex])orte'd  tyjie'  freem  anothe'r 
t\]>e'  impeerte'd  as  a  '^e'lie'iie-  parameter.  In  orde-r  tee  a])])ly  multiple'  exte-nsions  tee  a 
eeimpone'Ut.  use’  of  mixiu  inhe'iitance'  re’ejuire’s  chainiuy  e'xte’iisions  te)ji,('ther  tee  form  a 
linear  inhe-rii ane-e-  patli.  do  sui)|)e)rt  strueUiiral  interface  ceinfeuniane'e' of  eaedi  coneuete 
e'xte'iisie)!!  ceemjieeiient  tee  an  ahstiae't  e’xte’iision  ce)mpone'nt  re’ciuiie's  an  inlu'ritance 
ehain  tliat  alte'rnate's  he’twe'e’ii  abstract  and  cone’ie'te’  ty|)e.s. 

.An  abstrae  t  e’xte'nsie)n  compeuient  is  eiu'exle'el  in  R.A95  as  a  f-enerie'  chilel  unit  of 
tlie  abstrae-t  com])e)nent  it  ('xte-nrls.  By  ceniventieui.  t  he  paeTage  name  of  t  he  chilel  unit 
is  the'  name'  eef  the’  ])are’nt  unit  feilleiwe'el  by  a  pe’iioel.  feillowed  by  the'  string  "With,", 
feillove’d  by  a  name'  de’se  ribing  tlx'  ne’w  fnnctieinality.  Feer  ('xamph'.  the  abstract  tem¬ 
plate'  AT. Queue  .V/ith_Reverse  ('Xte'iiels  AT.Queue  by  a  .sjie'cificatieen  of  the  (luene  re- 
\e’).--e’  fniKt ie)nalit\ .  In  ge'iie’ral.  it  might  Ix'  possible'  feer  a  single'  abstract  exte'iision 
ceunpone’iit  tee  e'xte’iid  nieire'  than  one'  abstrae  t  ceunpeenent.  In  R.A05.  he)W('\er.  (’ach  ab- 
strae  t  exte’nsieui  is  ix’rmane’ntly  linke-el  tee  a  single  six’cifie’atiein  that  it  exte'iids.  Thus, 
the  extends  le’lationship  is  e’uceiele’d  dire’ctly  intee  eaeh  abstrae  t  e’xt e’lrsieui  ceimpeuient 
in  R,A95. 

Ligiire'  -i.If)  sheiws  the'  R.Ar).)-s])e'cifie-  C'll)  de’picting  the'  parent-cliilel  re’latieinship 
be'twe'en  a  kerne'l  abstract  ceunixment  and  an  abstrae’t  e’xtensieui  compement.  In  this 
examieh'.  the’  abstrae-t  pare'iit  unit  AT.Queue  is  ene-lose'el  in  AT.Queue . With.Reverse. 
the'  abstrae-t  (hihl  unit.  l  igiire’  5.10  a])pe’ars  similar  tei  Eignre  5.4  since  R.A95  uses 
sitnilar  language’  me’e  hanisms.  tyjK'  ('xte'iisiou  anel  hie’rare-hic-al  library  tinits.  to  emode’ 
implements  anel  extends,  dhe-  primary  dillerene-e  is  that  AT.Queue  .With.Reverse 
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Figure  5.10:  Abstract  Parent  and  Abstract  Child  Extension 


exports  an  abstract  type  whereas  AT_Queue .  CT_2  exports  a  fully-implemented  con¬ 
crete  type. 

The  specification  parameters  section  of  an  abstract  extension  component  has  a 
single  specification  parameter  which  serves  to  support  chaining  of  extensions.  This 
parameter  is  encoded  as  a  formal  generic  derived  type.  The  name  of  the  formal  pa¬ 
rameter  is  the  name  of  the  exported  type  prefixed  with  the  string  “Base_” .  The  actual 
parameter  corresponding  to  this  formal  parameter  is  constrained  to  be  a  concrete  type 
derived  from  the  abstract  type  exported  by  the  abstract  parent  unit  being  extended. 
For  example,  AT_Queue .  With_Reverse,  shown  in  Figure  5.10,  has  the  specification 
parameter  Base_Queue.  The  dotted  line  between  the  type  exported  from  AT.Queue 
and  the  line  extending  from  the  specification  parameter  conveys  the  constraint  on  the 
actual  parameter  for  Base_Queue.  Note  that  the  actual  parameter  need  not  be  derived 
directly  from  the  abstract  type  exported  by  (an  instance  of)  the  parent  unit.  The 
actual  parameter  may  be  the  result  of  many  extensions  to  that  type.  This  flexibility 
allows  multiple  extensions  of  the  same  abstract  component  to  be  chained  together. 

The  interface  section  of  an  abstract  extension  component  includes  an  exported 
abstract  type  publicly  derived  from  the  formal  generic  type  parameter.  The  name 
of  the  exported  type  is  the  same  as  the  name  of  the  abstract  type  from  which  it  is 
derived.  (The  exported  type’s  full  name  includes  its  package  name,  thus  distinguishing 
it  from  its  parent  type.)  This  derivation  provides  the  mixin  inheritance.  Furthermore, 
the  exported  type  is  a  null  record  extension  of  the  type  imported  by  the  generic 
parameter.  The  null  record  extension  means  that  the  abstract  extension  component 
does  not  augment  the  representation  of  the  imported  type.  In  Figure  5.10,  the  line 
connecting  the  Base-Queue  specification  parameter  to  the  abstract  type  exported 
by  AT_Queue .  With-Reverse  depicts  the  mixin  inheritance  link.  The  abstract  type 
exported  by  an  instance  of  AT_Queue .  With_Reverse  has  as  primitive  operations  the 
abstract  queue  reverse  operation  specified  in  the  extension  plus  all  concrete  operations 
of  the  type  used  as  the  actual  parameter  for  Base-Queue. 

The  remainder  of  the  interface  section  includes  usually  one,  but  possibly  more, 
abstract  subprogram  specifications.  Each  subprogram  specification  corresponds  to 
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Jill  opt'nttion  i)n)vi(liiij;  new  fiiiicl ioiijility  to  llir  ahslnict  n)m])oii('iit  Ix'iiis  rxtoiuh'd. 
Stnu  iiiml  coniiiif'iits  foriii;illy  dcscrilx'  iIh'  fiincl ioiia!  Ix'liavior  of  tlir  abstract  opcr- 
arioiis. 

l  isriirc  0.1  1  shows  the  Ada  packa,u,('  s|x'cificat ion  ciicodiiit-  tlx'  al)stract  t('nii)latc 
AT_Qu6ue . V/ith  .R©v6rsG.  Xo  pa('kat!,('  body  is  rcfinircd  as  with  abstract  kcriu'l  com¬ 
ponents.  \ot('  that  normally  tlic  added  operation  to  ivvrrsr  a  queue  would  be  named 
Reverse  instearl  cd  Reverse.Queue.  Since  reverse  is  a  re.sc'ived  word  in  Ada,  liow- 
e\ei.  it  cannot  be  used  as  an  operation  namt'.  Also  note  that  reverse  is  a  built-in 
Operation  of  the  striny  theory  mathematics  in  RlkSOIA'E's  sitecification  sub-Ian, <;naye. 
1  his  ('xplains  how  t  he  (uisures  elan.sf'  of  Reverse_Queue  may  be  exitresstvl  so  concisely. 


5.6.2  Implementation  of  Abstract  Extension  Components 

Recall  from  .St'ction  d.-).2  the  three  a])])roaehes  to  im])l('mentiu,t!,  an  extension  com¬ 
ponent:  layered,  direct,  and  con])led  imidenientations.  Since  the  RESOIA'E  discipline 
|)iimruil\  afbotates  use  of  tlx'  layered  approach,  the  strat(',y'\'  lor  encorlinc,  th(’  ex¬ 
tends  lelationship  in  R.AO  )  was  d('si,it|n('d  to  Ixrst  support  Itivt'red  imphunentations. 
In  this  st'ction  wt-  di.seuss  how  to  enetxle  a  layt-red  iinitleim'ntation  of  an  abstract 
ext f’lisicn  coinpDiH'nt . 

1  Ilf’  iniplf’iiirnt  at  ion  of  a  coiicrotf'  ('Xt(Misif)n  coiii])on(Mit  is  ciK^och'd  in 

HAO.)  as  a  ,^(‘iHa'io  cliild  unit  of  tlu'  ('xt(nision  (‘onipoiu'iit  it  iinj)l(niionts.  TIh'  pro- 
fix  of  child  unit's  packa,^('  name  is  tlx'  name  of  the  abstract  extension  component 
(the  jianuit  unit  name)  followed  by  a  ix'riod.  .Itist  lib'  imph'inentatifins  of  b'rnel 
comix, nents.  the  natue  ends  with  the  string  -CTJ'  followt'd  by  a  ntimber  idt'iitifying 
tlx  s]x  ( ifi(  im |)l('ment a t ioti .  hor  exatnph'.  the  concrt'te  (‘xtension  com]x)n('nt  name 
AT_Queue . V/ith_Reverse . CT^l  denotes  the  first  concrete  ti'inplate  that  imph'uu'nts 
the  reverse  compoiH'tit  that  extends  thecineue  abstract  t('m])late.  Again,  the  compo¬ 
nent  name  is  Ix'st  inter|)ret('d  from  right  to  left. 

l  iciire  .).]2  shows  tlx'  R.AOb-speeifie  C'lD  dt'picting  tlu'  parent-child  rt'Iatioiiships 
betwet'ii  a  kernel  abstract  component,  att  ab.stract  extension  compotK'nt.  atid  a  layered 
conerete  extension  component.  In  this  example,  tin'  abstract  extension  component 
AT_Queue.With_Reverse  (Ei.gure  r,.l])  is  enclosed  in  AT.Queue . With.Reverse . CT_1. 
the  concrete  child  miit. 

A  concrete  extension  conii)onent  consists  of  a  package  specification  and  bodv 
uhich  are  similar  in  strnctnrt'  to  those  of  a  kernel  conen'tt'  com]X)tient.  The  jiaekagt' 
si)t'cification  includes  ati  interfaet' .section,  a  re))resentat  ion  exti'iision  section,  atid  pos- 
sibl\  an  imiih'UH'nt  at  ion  ])aram('t  ers  si'ction.  1  he  inti'iface  si'ction  inelndes  a  concrete 
ex]xirt('d  ty|)e  and  eonereti'  subprogram  specifications,  .brst  as  with  kernel  concn'ti' 
components,  the  exported  tyjx'  is  a  ])rivat('  tyjx'  extension  of  the  abstract  type  ex- 
ported  by  its  ])ar('nt  unit.  This  inh('ritanee  link  is  shown  in  Eigure  5.12  as  tlu'  line 
conneeting  the  abstract  type  exported  fioni  AT_Queue .  With_Reverse  to  the  conen'te 


-  -  Compon  ent :  AT_Queue ,  Wit  h_R  averse 
--  Relations :  extends  AT_Queue 

Comments:  'Reverse '  is  an  Ada  reserved  word,  hence  Reverse_Queue 


--  Global  Context 


generic 


--  Specification  Parameters 


type  Base_Queue  is  new  AT_Queue . Queue  with  private; 


package  AT_Queue . With_Reverse  is 


--  Interface 


type  Queue  is  abstract  new  Base_Queue  with  null  record; 


—  Added  Operations 


procedure  Reverse„Queue  ( 

q  :  in  out  Queue  preserves  g 

)  is  abstract; 

--!  ensures 

--!  q  =  reverse (#q) 


end  AT_Queue . Wi th_Reverse ; 


Figure  5.11:  Package  Specification  for  AT_Queue.With_Reverse 


T 


j  in;;;;; — n 

Queue 

AT_Queue  H 


AT_Queue.With_Reverse 
AT_Queue.Wjth_Reverse.CT_1 

,  AT  Stack 


I- idlin'  t.l'i:  Al)strjict  Pjirt'iit  and  C'oncn'tc  Child  Extension 


txpe  exported  hy  AT_Queue.With_Reverse.CT_l.  In  tliis  ('xaniple.  both  type's  an- 
naniefl  Queue  (as  is  the  tyja'  exported  Ity  AT_Queue). 

Derivation  of  tlie  ('xi)orted  concrete  type  in  tli('  jtidtlic  part  of  the  packagt'  pro- 
\  ides  a  partial  \‘iev  of  the  ty])e  and  ensnre's  that  the  concrett'  operations  iniporte'd  1)V 
the  parent  unit  are  re-t'xjtorted  alon.y  with  the'  concrete  exjtorted  tyjte.  For  example, 
the  actinil  j)araniet('r  for  Base_Queue  in  F  i.ti,nr('  .:).]2  may  include  many  (’xtensions 
to  AT_Queue.  However,  the  body  of  AT_Queue.With_Reverse.CT_l  only  has  visibil¬ 
ity  to  tlu'  ojjerations  ch'scribefl  by  AT_Queue .  With_Reverse  (which  include  those  of 
AT_Queue ). 

The  interface  section  also  includes  out'  concrete  sub])roc,ram  sjx'cification  corrt'- 
spoiifliny  to  each  abstract  ojteration  added  by  the  pan'iit  unit  to  rh'.scribe  new  func¬ 
tionality.  1  he  r('])re,sentat ion  ('xtt'iision  section  is  in  tlu'  privatt'  part  of  the  ])ackage 
and  contains  the  declaration  of  tlu'  export t'd  tyjte  [tnu-idiny  its  full  view.  Tlu'  exported 
t\p('  is  a  nidi  record  exti'iision  of  tlu*  abstract  type  ('X])orted  by  the  part'iit  unit.  TIk' 
implementation  paranu'ters  section,  if  prest'iit.  s('r\'es  tlu'  stune  roh'  as  in  ki'iiu'l  con- 
en'te  comiionents.  Fi.yure  .").]‘2  shows  tlu'  imjilement  at  ion  paranu'ti'r  AT_Stack  used 
to  exjiress  the  needs  relat ionshi])  AT_Stack.  Thus.  AT_Queue.With_Reverse.CT_l  is 
layered  on  toj)  of  imiilement  at  ions  of  bot  h  AT_Stack  and  AT_Queue. 

The  ])ackaye  borlv  of  a  concrete  extension  conpioiK'nt  includes  one  subprogram 
body  corresponding  to  each  added  opt'iation.  Like  its  keriK'l  compoiH'tit  connt('r])art. 
it  also  ma\  include  a  local  operations  section  to  j)ro\id('  local  snbju'oftrams  usc'd  to 
imiilement  the  exjiorted  operations. 

Fiuure  .l.l.T  shows  tlu'  .Ada  i);uka”{'  s])ecification  for  the  concrett'  ('Xtt'iision  com¬ 
ponent  AT_Queue  .  V/ith_Reverse .  CT_1.  F  igiire  •’).]1  shows  tin' corresjionding  package 
bofly  with  till'  hiyered  im])lem('ntat ion  of  the  Reverse_Queue  opt'ration. 
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“ “  Component :  AT_Queue .  Wi  th__Reverse .  CT_1 

--  Relations :  implements  AT_Queue ,With_Reverse,  needs  AT_Stack 
Comments :  Reverse_Queue  reverses  a  queue  using  a  stack 


Global  Context  - 

with  AT_Stack; 

generic 

--  Implementation  Parameters  - 

with  package  AI_Stack  is  new  AT_Stack  (Item  =>  Item) ; 
type  Stack  is  new  AI_Stack . Stack  with  private; 


package  AT__Queue .  With_Reverse .  CT_1  is 


--  Interface 


type  Queue  is  new  AT_Queue .Wit h_Reverse . Queue  with  private; 


--  Added  Operations 


procedure  Reverse_Queue  ( 

q  :  in  out  Queue 

)  ; 


private 


--  Representation  Extension 


type  Queue  is  new  AT_Queue .With_Reverse . Queue  with  null  record; 


end  AT_Queue . With_Re verse . CT_1 ; 


Figure  5.13:  Package  Specification  for  AT -Queue. With_Reverse.CT_l 
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--  Cor.ror.cr.:: 
--  RclaTionF 
Co—.cr.^s 


AT_Qucuc . Wi th_Rcvcrsc . CT_1 

in:plcn-,cnt:s  AT_Qucuc .  Wi  th_Rcvcrso ,  needs  AT_Stack 
Rcverse_Oueue  revez'ses  a  queue  using  a  stack 


package  body  A7_Qucuc  .  V/i  th_Rcvcrsc  .  CT_1  is 


-  -  /:  d d  c  d  Op  c  r a  t  i  on  s 


procedure  Rcvc::sc_Qucuo  ( 

G  :  in  out  Queue 
)  is 

s  :  Stack; 

X  :  Iter:.; 

Icr.gth  :  Integei:  :  =  0; 

begin 

Got__Lcr.gth  (q,  length)  ; 
while  length  >  0  loop 

alters  q,  s,  length 
consumes  x 

~~I  m^aintains  I'evez^se  ( s )  *  q  - 

length  =  Iql 
~-I  deci^cases  Iql 
Dequeue  (q,  x) ; 

Push  (s,  x) ; 
length  :=  length  -  1; 
end  loop; 

Get_Lcngth  (s,  length); 
while  length  >  0  loop 

--I  alters  q,  s,  length 

cons:;n:cs  x 


end 


~~ I  maintains  q  *  s  = 
decreases  Iql 
Pop  (s ,  x)  ; 

Enqueue  (q,  x)  ; 
length  :=  length  -  1; 
end  loop; 

Rcverse_Qucuo; 


II  q  *  II  s 


rci^crsc  f j  *  llq  and 


and  length  =  Is  I 


end  A . _Queue  .  V:i  th_Reverse  .  Ci„l ; 
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Fi,iiur('  o.M:  Package'  Body  for  AT_CJuc'U{'.\\'it li^R('V('rs('.CT_] 


5.7  Other  RESOLVE/ Ada95  Relationships 

The  uses,  implements,  needs,  and  extends  relationships  each  address  a  fun¬ 
damental  issue  of  software  engineering.  These  relationships  are  likely  to  appear  in 
one  form  or  another  in  any  discipline  for  component-based  software  engineering.  The 
specializes  and  checks  relationships  described  in  this  section  arise  from  following 
the  principles  of  the  RESOLVE  discipline.  The  reader  unfamiliar  with  RESOLVE 
may  find  these  two  relationships,  especially  checks,  new  and  interesting. 

5.7.1  The  RESOLVE/ Ada95  specializes  Relationship 

As  we  discussed  in  Section  5.3,  one  of  the  principles  of  the  RESOLVE  discipline  is 
that  implementations  should  be  fully  parameterized.  In  terms  of  component  relation¬ 
ships,  this  means  that  design  dependencies  should  be  expressed  in  terms  of  needs, 
instead  of  uses,  whenever  possible.  In  addition  to  reducing  component  coupling, 
this  approach  also  supports  parametric  adjustment  of  the  performance  character¬ 
istics  of  concrete  components  [Sit92].  For  example,  the  performance  of  the  queue 
implementation  AT -Queue .  CT_2  shown  in  Figure  5.7  depends  on  which  One-Way  .List 
implementation  a  client  provides  as  an  implementation  parameter.  The  client  of  this 
component  may  “tune”  the  performance  of  a  concrete  component  by  choosing  among 
different  implementations  of  the  components  it  uses. 

The  disadvantage  of  fully  parameterized  concrete  components  is  that  they  are 
more  difficult  for  clients  to  use.  For  example,  most  client  programmers  who  want 
to  use  a  queue  component  in  their  application  will  not  want  to  be  bothered  with 
selecting  a  list  implementation.  (The  list  implementation  might  also  require  its  own 
implementation  parameters,  and  so  on.)  The  RESOLVE  framework  solves  this  prob¬ 
lem  with  a  specialization  component.  A  specialization  component  is  a  concrete  com¬ 
ponent  for  which  some  and  usually  all  of  the  needs  relationships  have  been  fixed  to 
uses  relationships.  That  is,  specialization  components  are  not  fully-parameterized. 
A  specialization  component  is  produced  by  internally  instantiating  implementation 
parameters  of  a  fully  parameterized  component  and  then  re-exporting  the  interface 
and  behavior  of  the  resulting  instantiation.  A  RESOLVE  component  library  may 
contain  several  specialization  components  associated  with  each  fully  parameterized 
kernel  concrete  component. 

The  specializes  relationship  is  a  special  case  of  the  uses  relationship.  We  define 
the  specializes  relationship  informally  as  follows: 

Concrete  component  C2  specializes  concrete  template  Ci  if  and  only 
if  C2  uses  C\  and  all  behavior  implemented  by  C2  is  provided  by  an 
instantiation  of  C\. 

A  specialization  component  is  a  concrete  component  that  specializes  another 
concrete  component.  The  component  coupling  diagram  in  Figure  5.15  depicts  the 
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specializes 


AT_Queue.CT_2a 


o.lT):  J\\v  specializes  Rc'lationship 


specializes  rrlationslii])  Ix'twfHMi  two  vowrvvW  (•()in])()nriits:  AT.Queue .  CT.2a  and 
AT.Queue .  CT_2.  AT_Queue  .  CT_2a  is  a  s])(H*iali/ati()n  (•oin])oii(ait  which  ch'jx'iids  on  the 
fnlly-])a ranu't eri/(‘fl  iin])l('nir'nt ation  AT„Queue  . CT_2,  In  this  exani|)l(\  th('  special¬ 
izes  ndationshi])  indicates  that  AT„Queue . CT_2a  has  hecni  cn^ated  hy  int('rnally  in- 
sT  ant  iaT  iim;  AT^Queue  .  CT_2.  Within  AT_Queue  .  CT_2a.  oiu’  ])articnla]'  coin])onent  that 
implements  AT_One_Way_List  must  ])v  used  as  th('  iniphniunitation  ])aranieter  to 
instantiate'  AT.Queue . CT_2.  J  In^  inteu’face'  and  Ixdiavior  ('X])ort('d  hy  tlu'  inteu'iial  in¬ 
stantiation  of  AT.Queue  . CT. 2  is  n'-('X])ort('d  as  the*  coin])I('t('  inteuTae^e  and  Ixdiavior 
of  AT.Queue .  CT.2a. 

Sf'Vf'ra!  implicit  ndationslii])s  not  shown  in  Kii!,ur('  5.15  may  Ix'  (h'diicexl  from 
those'  sliown.  first.  AT.Queue .  CT_2a  uses  AT.Queue  .CT. 2  hy  the  dedinition  of  spe¬ 
cializes.  Sf'cond.  AT.Queue .  CT_2  also  uses  some'  com]x)nent  wliich  implements 
AT.One.V/ay.List  hex-anse'  of  tlx'  uses  r('lationshii)  shown.  Tliird,  and  most  imi)or- 
tant.  AT.Queue . CT. 2a  implements  AT.Queue  Ix'cansc'  of  tlx'  implements  ix'lation- 
shii)  shown.  ]  hns.  an  instatux'  of  AT.Queue .  CT. 2a  is  Ixdia\'iora!ly  snhstitntahh'  for 
an  instaiKx'  of  AT.Queue .  CT. 2  with  ix'sjx'ct  to  AT.Queue.  Tlu'  difference  Ix'twtx'ii 
thesf'  two  implf'nu'iitations  of  AT.Queue  is  that  tlu'  non-fmuTional  cliaracttnistics  of 
AT.Queue . CT. 2a  hav('  lx'(m  fixt'd  wliih'  sonu'  of  the  non-fnnctional  charact('rist ics  of 
AT.Queue  .CT. 2  may  still  Ix'  afljnsttxl. 

A  s]xx-iali/at ion  com])onent  is  ('ix’odc'd  in  HAOo  as  a  gt'ix'ric  cliild  unit  pat'kage 
spf‘cifi('ation.  No  corresponding  package'  body  is  ixx'ch'd.  Tlx'  })ar('nt  unit  is  tlx'  ab¬ 
stract  comi)onent  whicli  tlx'  com]x)nent  being  si)eciali/('d  (atid  tints  also  tlie  sjtecial- 
i/ation  (‘omjxxif'nt  its('lf)  im])l('nients.  By  conve'itt ion,  tlx'  name  of  a  sp(x*iali/ation 
com])onf'nt  is  tlx'  sanx'  as  that  of  tlx'  component  it  specializes  a])]x'nd('d  with  a 


single  letter  used  to  distinguish  between  multiple  specializations  of  the  same  compo¬ 
nent.  For  example,  the  name  AT_Queue .  CT_2c  identifies  the  “third”  specialization  of 
the  “second”  implementation  of  the  queue  abstract  template. 

A  specialization  component  contains  a  global  context  section,  an  interface  sec¬ 
tion,  a  local  instantiations  section,  and  a  representation  section.  Typically  all  of  the 
parameters  of  the  component  being  specialized  are  fixed.  In  this  case,  there  will  be 
no  implementation  parameters  section  and  no  generic  formal  parameters.  The  fixed 
dependencies  on  the  component  being  specialized  and  on  the  components  selected 
to  serve  as  implementation  parameters  appear  as  with  clauses  in  the  global  context 
section.  The  interface  section  of  a  specialization  component  declares  the  exported 
concrete  type  as  a  private  type  extension  of  the  abstract  type  exported  by  the  parent 
unit.  This  partial  view  of  the  exported  type  assures  that  a  client  of  this  component 
has  visibility  to  all  operations  described  in  the  abstract  parent  unit.  The  implemen¬ 
tations  of  these  operations  are  provided  in  the  private  part  and  thus  no  operations 
need  to  be  declared  in  the  interface  section. 

The  private  part  of  the  package  contains  the  local  instantiations  and  representation 
sections.  The  local  instantiations  section  contains  all  package  instantiations  necessary 
to  supply  actual  parameters  to  the  final  instantiation  in  this  section.  The  final  instan¬ 
tiation  creates  an  instance  of  the  component  being  specialized.  This  package  instance 
supplies  the  concrete  type  to  be  re-exported  by  the  specialization  component.  The 
representation  section  consists  of  a  null  record  extension  of  the  concrete  type  to  be 
re-exported.  This  type  extension  creates  the  full  view  of  the  concrete  exported  type. 

An  example  of  a  specialization  component  is  AT_Queue .  CT_2a.  This  component  is 
a  concrete  template  which  specializes  AT_Queue .  CT_2  (Figure  5.5)  and  uses  the  spe¬ 
cialization  AT_One_Way_List  .CT_la  (not  shown)  to  instantiate  AT.Queue .  CT_2.  Note 
that  AT_Queue .  CT_2a  implements  AT_Queue.  Figure  5.16  shows  a  component  in¬ 
stantiation  diagram  detailing  how  AT_Queue .  CT_2a  has  been  implemented.  From  the 
information  summarized  in  this  diagram,  it  would  be  straightforward  for  a  tool  to 
automatically  generate  the  Ada  code  for  AT_Queue .  CT_2a  shown  in  Figure  5.17. 

The  local  instantiations  section  of  AT_Queue .  CT_2a  includes  three  package  instan¬ 
tiations.  The  first  creates  AI_One_Way_List,  an  instantiation  of  AT_One_Way_List 
with  the  same  Item  type  as  AT_Queue.  This  instantiation  is  depicted  in  Figure  5.16 
by  the  line  connecting  the  Item  specification  parameter  of  AT.Queue  to  that  of 
AT_One_Way_List  on  the  left  side  of  Figure  5.16.  The  second  instantiation  creates 
CI_One_Way_List,  an  instantiation  of  AI_One_Way_List  formed  by  selecting  the  “la” 
implementation  of  AT_One_Way_List.  This  instantiation  is  depicted  by  showing  the 
implementation  AT_One_Way_List.CT_la  around  the  specification  AT_One_Way_List 
in  the  lower  left  corner  of  the  figure.  The  final  instantiation  creates  CI_Queue, 
a  concrete  instance  of  AT_Queue  .CT_2,  the  component  being  specialized.  This  in¬ 
stantiation  is  depicted  in  Figure  5.16  by  placing  the  AT  .Queue .  CT_2  implementation 
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I  i.t;iir('  a.lf);  A  Dctailc'd  of  AT^Queue .  CT_2a 


arniiiKl  tli('  AI_Queue  s])('cifi(at ion  and  hy  the  lino  coniu'ct iny  tlu'  typt'  ('X])ort('d  hv 
AT_OneA.'ay_List . CT_la  to  tlic  ini])l('nu'ntation  ])arani('t('r  of  AT.Queue  . CT_2. 

tliat  tin’  conpjonont  nanio  AI_Queue  in  Fi<;nr('  5. 10  ndors  to  an  instance 
of  AT.Queue  wirli  tlic  type  Item  fixed.  Within  the  cliild  unit  AT_Queue . CT_2a,  the 
package  name  AT_Queue  ini])licit ly  refers  to  this  package'  instance',  an  instane-e'  e)f  its 
ge'iie'rie-  |)are'nt  unit.  In  Figure'  a.lfi.  the'  line-  fre)in  the  ty])e'  expe)rte'el  l)y  AT.Queue  . CT_2 
te.  the  type-  ex])e)rte'd  In-  AT_Queue .  CT_2a  elej)ie-ts  the-  inhe'iitane-e'  link  he'twe'cn  tlie'se 
tv.-o  ty])e's.  I  he  nnll  recorel  type'  e'xte'iisieen  at  the'  enel  e)f  AT.Queue . CT_2a  ene'oele's  this 
inhe'riianee'  link. 


5.7.2  The  RESOLVE/Ada95  checks  Relationship 

I  his  see  tion  ele'se-rihe's  chcchinf/  conipoiiculs  anel  the'  asse)e  iate'd  checks  relatie)n- 
ship.  C'he'e-king  e-oinponents  are'  ^•e'ry  nse'ful  ce)ini)e)ne'nts  within  the'  RFSOIA'E  franie'- 
woik.  d  he'ir  utility  large'lv  re'snlts  fre)ni  the'  laye'ie'el  way  in  whie'h  RFS()L\  E  e'eeinpo- 
ne'iit^  are'  elesigne'd  anel  inii)le'ine'nte'el. 

One'  eif  the'  ])rine  iple's  e)f  the'  RFSOIA'E  eli,se  i]>line'  is  that  clie'iits  .sheuilel  he  re'spon- 
sihle'  for  ehe'e-king  the'  ])re'e-e)nelit ions  e)f  eepe'iat ie)ns.  This  approae-h  a\e)iels  tmnee'e’ssary 
ine'ffie-ie'iK'y  anel  siinjelifie's  conipement  ini])le'ine'ntatie)ns.  Fnrt hermeere'.  it  re's])ee-ts  the' 
e-euitrae-tnal  re'lationshi])  e'xpre-.sse'el  hy  the'  implements  relatieenshi]).  A  ce)nipe)ne'nt 
iinple'ine'iite'r  is  re's])onsil)le'  fe)r  prewiding  all  he'havie)!'  ele'se-rihe'el  hy  the'  ahstrae't  ce)ni])e)- 
ne'iit  anel  no  more'.  If  a  e  e)ne-re'te'  e  e)mpe)ne'nt  must  hanelle'  exe-e])tie)nal  events,  tlie'ii  the 
ahstraet  te'inplate'  she)nlel  ch'se-rihe'  what  he'havie)!'  is  re'qnire'el  for  exe'eptie)nal  events. 
If  a  e  lie'iif  use's  an  e)pe'ratie)n  whe'ii  its  pre'e'eenelit  ie)n  is  ne)t  satisfie'el.  the'ii  the'  ceene  rete 


--  Component:  AT_Queue , CT_2a 

--  Relations :  specializes  AT_Queue . CT_2 ,  uses  AT_One_Way_List . CT_la 
Comments :  - 


--  Global  Context 


with  AT_Queue . CT_2 ; 

with  AT_One_Way_Li St . CT_la ; 


generic 

package  AT_Queue . CT_2a  is 


Interface 


type  Queue  is  new  AT_Queue . Queue  with  private; 


private 


--  Local  Instantiations 


package  AI_One_Way_List  is  new 

AT_One_Way_List  (Item  =>  Item) ; 

package  CI_One_Way_List  is  new 
AI_One_Way__List .  CT_la; 


package  CI_Queue  is  new 
AT_Queue . CT_2  ( 

AI_One_Way_Li s  t 
List 


)  ; 


=>  AI_One_Way_List , 

=>  CI__One_Way_List .  List 


Figure  5.17:  Abstract  Template  AT_Queue .  CT_2a 
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type  Queue  is  new  CI_Oucuc . Queue  with  null  record; 


end  AT_0ueue.CT_2a; 


I- .j.  18:  Ahstraci  'J'niiplaK' AT_Queue  . CT_2a  (C'ontiniu'fl) 


cc)!!!]  iDiif'iii  {'Xj )( lit  ill”  that  ojicrat  ion  is  fn’c  to  do  aiiyt  hi  up,  or  iiotliinp  from  that  point 
on. 

Particnlarl}'  diirinp  the  tt'stiii”  and  (h'hiippinp  of  lU'w  iinph'nK'iitations.  tintoliahh' 
code  may  ('iToiicoiisly  call  ojicrat ions  witli  ^•iolat(■d  preconditions.  In  RES()L\'E.  the 
lieha\‘ior  of  the  implementations  is  nnspecifii'd  onc('  a  precondition  violation  taki's 
placi'.  As  a  result,  locating  errors  while  delitippin”  may  Ix'  very  diflicnlt.  Thus, 
checkiu”  the  iirecondit  ions  of  op(>rations  is  useful  when  tlu'n'  is  a  lack  of  confidenci'  in 
the  correctiH'ss  of  implenn'iilations  within  a  software  systimi.  A  ch('ckin,p  com])onent 
aridres'^es  tlii.-^  ])rol)lem  hy  clu'ckin,”  operation  im'conditions  before  calliti”  unproteett'd 
opera t  ion  im])lem('niat  ions. 

.-\  checkin.”  component  is  a  concrete  com])on('nt  with  characti'rist ics  similar  to  both 
an  ('Xlension  compoiH'iit  and  a  concrc'te  compoiu'nt.  Like  an  exti'iision  component, 
it  afhL  new  functionality  to  another  comiioiu'iit.  'J'he  additional  behavior  consists 
of  checkin”  to  set*  if  a  ])reconrlii ion  is  satisfied,  and  if  not.  reportin.p  tin'  \  iolation 
and  haliiii”  exf'cution  of  the  ])ro”ram  immediati'ly.  I’nlike  an  extension  compoiH'nt. 
however,  a  checkin,”  compoiK'iit  provides  no  additional  s])('cifi('d  behavior.  Lik('  a  typ¬ 
ical  concrete  compoiifMit.  a  checkin”  com])onent  pro\'id<'s  the  intiufaci'  and  bcdiavior 
specified  by  an  abstract  teinfilati'.  flowever,  a  checkin,”  com|)on('nt  does  not  dirt'ctlv 
])ro\idc  the  sjiecified  functionality  it  ('xjxirts.  fnsti'ad.  a  clx'ckin,”  component  uses 
th”  abstract  K'nijilate  which  it  implements  to  jirovich'  its  ('.xportt'd  Ix'havior.  That 
i>.  a  checkin”  comiioiu'nl  is  im])lem('nted  by  layerin,p  tlu'  clx'ckin,”  functionality  on 
top  of  a  concrete  com])onent  that  pian'ides  tin'  desiri'd  sjiecified  Ix'havior.  ThertTore. 
a  sinple  checkin,”  compoiKUit  ma,\'  lx*  nscxl  to  clux-k  any  concrete'  comixun’nt  whicli 
implements  t he  abst fact  comjxinent  it  checks. 

The  checks  relationshi|)  ex])r(’.s.s('s  part  of  the  dejiendency  betwe'en  a  concrete' 
eom])onent  anel  an  abstiae-t  eeimpeine'nt .  The'  checks  re'lal ieinship  may  lie'  de'fine'el 
informally  as  follows: 


AT  Queue 

V _ _ _ y 

j 

i 

checks 

J^AQue 

ue.CT_0 

Figure  5.19:  The  checks  Relationship 


Concrete  component  template  C  checks  abstract  component  A  if  and 
only  if  (a)  C  implements  A  and  (b)  C  immediately  reports  violations  of 
all  operation  preconditions  described  b}^  A. 

A  checking  component  is  a  concrete  component  which  checks  and  needs  the 
same  abstract  component.  It  is  possible  to  have  the  relationship  C  checks  A  without 
the  relationship  C  needs  A.  However,  such  a  C,  one  which  directly  implements  the 
behavior  of  the  component  it  checks,  would  not  be  nearly  as  useful  as  a  checking 
component. 

The  CCD  in  Figure  5.19  depicts  the  checks  relationship  between  the  checking 
component  AT_C)ueue.CT_0,  and  the  abstract  component  AT_Queue.  The  only  precon¬ 
dition  specified  by  AT_Queue  is  that  the  Dequeue  operation  may  not  be  called  with  an 
empty  queue  object.  Therefore,  if  a  client  of  AT_Queue .  CT_0  tries  to  dequeue  an  item 
from  an  empty  queue,  an  error  report  will  be  issued  and  the  program  will  halt.  Note 
that  in  the  case  of  a  checking  component,  the  needs  relationship  is  omitted  from  the 
CCD.  A  slightly  more  complex  notation  which  includes  template  parameters  makes 
explicit  this  uses  relationship  for  checking  components. 

A  checking  component  is  encoded  in  RA95  as  a  generic  child  unit  of  the  abstract 
template  which  it  checks.  By  convention,  the  package  name  CT_0  is  prefixed  by  the 
name  of  its  parent  unit.  Since  the  child  unit  has  direct  visibility  to  its  parent,  the 
uses  relationship  with  its  parent  is  implicit.  Thus,  the  global  context  section  in  a 
checking  component  is  empty.  The  implementation  parameters  section  contains  a 
single  generic  formal  derived  type.  The  name  of  this  type  is  the  name  of  the  exported 
concrete  type  prefixed  by  the  string  Base..  The  actual  parameter  for  this  formal  type 
must  be  a  type  derived  from  the  abstract  type  exported  by  the  parent  unit.  Thus, 
the  type  exported  by  any  component  which  implements  the  parent  unit  may  serve 
as  an  actual  parameter. 

Figure  5.20  shows  the  RA95-specific  component  instantiation  diagram  depicting 
the  parent-child  relationship  between  a  kernel  abstract  component  and  its  concrete 
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AT_Queue.CT_0 

Base  Queue 


o.if).  Ahstivu't  Par(Mit  and  C’oiicn^tc"  C'lir(‘kiiii»  C  hild 


vhrrkuvx  coiiipciKMit.  In  tliis  rx;un])I(‘.  AT.Queue .  CT_0  is  tlio  clirckin-  coinpoiirm  for 
AT.Queue.  Tlir  iinpIciiK'ntnt ion  paranirtcr  Base^Queue.  like  all  otlu'r  iini)l('niontation 
I)aranif'irrs,  is  sIkavii  aloii”-  tlir  bottom  (nlgr  of  tlin  concn'to  compoiK'tit ,  Tho  dotted 
line  eonveys  the  eonstraint  that  the  aetnal  parameter  supplied  for  Base.Queue  must 

be  a  type  (h-rived  (possibly  indirectly)  from  the  type  exiiorted  from  an  instance  of 
AT.Queue. 

I  he  interface  section  of  a  checking  component  package  sjiecificat ion  includes  the 
declaration  of  the  concrete  exiiortt'd  type,  'bhe  ('xj)ort('d  ty])e  is  a  null  record  extension 
of  the  imported  generic  formal  tyiie.  Thus,  the  re])resentation  of  the  com])onent 
on  which  th('  checking  component  is  layeird  is  not  altered.  The  inheritance  link 
establi^lH'd  by  this  type  extension  is  dejiicted  in  Figure  5.20  by  the  line  connecting 
the  Base_Queue  implementation  parameter  to  the  typi'  exported  by  AT_Queue . CT_0. 

for  each  oiieration  with  a  preconrlit ion  (aside  from  "true")  in  the  parent  unit,  the 
child  unit  inchid(>s  a  corresponding  concreti'  subimigram  signatuiT.  These'  o])erations 
override  those  with  matching  signatiin's  inh('rit('d  from  the  generic  tcjic  parameter. 
This  is  another  use  of  mixin  inheritance.  While  overriding  inherited  operations  is 
generally  a  threat  to  pn'.serving  behavioral  substitutability,  this  ove'rriding  is  safe  as 
Imiu  as  the  iFAnb  discijiline  is  followed.  It  is  saf('  becau.se  the  overriding  oiieration 
pin\idc>  th('  identical  specified  lichavior  as  the  overridden  oiieration,  when'  the  pri'- 

eondition  holds  (it  is  iiermitti'd  to  have  any  behavior  where  the  precondition  does  not 
h( ). 

The  jiackage  body  of  a  checking  component  jirovidi's  tin'  imph'inentations  of  each 
(Acniding  operation.  I  he  body  of  I'ach  ot’c'n-iding  opc'iation  first  checks  to  sc'c  if 
the  iin'condition  for  that  o])eration  is  satisfied.  One  of  HESOIT'E's  guidi'lines  for 
th('  seh'ction  of  luimitive  operations  is  that  they  include  any  operations  nece.ssary  to 
c  hi'ck  all  iireconditions.  'J'h('n'fore,  tlu'  code  to  check  the  jnecondit ion  may  be  layi'ied. 
Once  the  ch('ck  is  made,  soiik'  mechanism  must  be  used  to  n'])ort  tin'  error  and  halt 
the  progratn.  if  neci'.ssary,  J  Ik'  idi'al  iiK'chanism  usi'd  ch'pi'uds  ujion  tin'  run-time 
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environment  in  which  the  RA95  programs  will  be  run.  Many  Ada  compilers  provide 
an  Assert  pragma  which  is  useful  for  this  purpose. 

If  there  are  no  precondition  violations,  the  body  of  the  overriding  operation  calls 
the  operation  it  has  overridden.  This  requires  use  of  Ada’s  view  conversion.  Inside 
the  body  of  the  overriding  operation,  a  formal  parameter  of  the  exported  type  is 
converted  to  the  type  of  its  parent  when  used  as  an  actual  parameter  in  the  call  to 
the  overridden  operation. 

Figure  5.21  shows  the  RA95  package  specification  for  the  checking  component 
AT_queue .  CT_0.  Figure  5.22  shows  its  package  body.  AT_Queue .  CT_0  is  a  concrete 
template  which  checks  the  kernel  abstract  component  AT_Queue  shown  in  Figure  5.1. 
The  implementation  shown  here  depends  on  the  Assert  pragma  as  implemented  by 
the  GNAT  Ada  compiler. 


5.8  Instantiation  of  RESOLVE/ Ada95  Components 

In  this  section  we  briefiy  explain  and  provide  an  example  of  how  RA95  compo¬ 
nents  may  be  instantiated  to  form  concrete  instances  which  may  be  used  directly  in 
applications.  Recall  that  a  concrete  component  is  a  subsystem  implementation  for 
which  all  parameters  have  been  fixed.  Thus,  a  concrete  component  exports  a  con¬ 
crete  type  which  may  be  used  directly  by  another  component  or  application  program. 
In  Section  5.7.1,  we  explained  the  instantiation  of  several  components  within  the 
package  specification  of  CT_Queue .  CT_2a.  These  local  instantiations  were  depicted  in 
Figure  5.16.  Instantiation  of  components  for  use  by  application  programs  is  similar. 

The  process  of  building  a  concrete  instance  generally  proceeds  as  follows.  First, 
a  kernel  abstract  instance  is  produced  by  an  instantiation  which  binds  the  specifi¬ 
cation  parameters  of  a  kernel  abstract  template.  Then  a  kernel  concrete  instance 
is  produced  by  an  instantiation  which  binds  a  specific  implementation  to  the  ker¬ 
nel  abstract  instance.  This  instantiation  may  involve  supplying  actual  parameters 
for  implementation  parameters.  Then,  if  necessary,  the  functionality  of  the  kernel 
concrete  instance  may  be  augmented  through  a  sequence  of  abstract  and  concrete 
extensions.  For  each  abstract  extension,  the  type  exported  from  the  most  recently 
constructed  concrete  instance  serves  as  the  actual  parameter  for  the  specification 
parameter.  Each  abstract  instance  created  by  an  abstract  extension  must  then  be 
supplied  with  an  implementation  in  the  same  manner  as  the  kernel  abstract  instance. 
Checking  concrete  instances  may  be  introduced  after  the  kernel  concrete  instance  has 
been  created.  A  checking  component  is  produced  by  supplying  a  concrete  instance  as 
an  implementation  parameter  to  a  checking  concrete  template. 

Figure  5.23  shows  a  CID  depicting  the  composition  of  components  to  form  the 
concrete  instance  CI_Enhanced-Integer_Queue_l.  This  concrete  component  pro¬ 
vides  the  behavior  specified  by  AT.Queue  extended  with  AT_Queue_With_Reverse  and 
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--  CG.*::ra’:c-f: ;  A7_Quc'jc .  CT_0 
-  -  Rcl  ati  or.s  :  chcckr.  AT_Qucuc 

Cor-.cr.ts :  GKAT  -a  switch  must  be  on  when  compiling  this  and  clients 


--  Global  Con t ex t 


generic 


“  -  Imp  1  er:  on  tat  ion  Parameters 


type  3asc_Qao'JC  is  new  AT_Oucuo . Queue  with  private; 


package  AT_Qucuc . C7„0  is 


--  Interface 


type  Queue  is  new  Ba5;e_Queue  with  null  record; 


--  Overriding  Operations 


procedure  Dequeue  ( 

c  :  in  out  Queue; 
X  :  in  out  It  err. 


end  7-. .  _Queuc  .  CT_0  ; 


I'iuurc  ").21:  Package  Sjx'cificat  ion  for  Abstract  Icniplatc  AT_Queue . CT_0 


--  Component:  AT_Queue .  CT_0 
--  Relations :  checks  AT_Queue 

Comments:  GNAT  -a  switch  must  be  on  when  compiling  this  and  clients 


--  Global  Context 


package  body  AT_Queue . CT_0  is 


--  Interface  Operations 


procedure  Dequeue  ( 

q  :  in  out  Queue; 
X  :  in  out  Item 


)  is 

length  :  Integer  :=  0; 

begin 

Get_Length  (q,  length) ; 
pragma  Assert  (length  >  0, 

"Dequeue  pre-condition  (q  /=  empty_string)  violated"); 
Dequeue  (Base_Queue (q) ,  x) ; 
end  Dequeue; 


end  AT_Queue . CT_0 ; 


Figure  5.22;  Package  Body  for  Abstract  Template  AT.Queue .  CT_0 


AT_Queue_With_Replica^®  (not  shown).  Note  that  a  component  library  suitable  for 
production  use  is  likely  to  contain  a  wide  variety  of  ready-to-use  concrete  instances^ 
especially  for  common  data  structures  such  as  queues.  Therefore,  it  is  unlikely  that 
a  component  library  user  would  ever  need  to  construct  this  concrete  instance. 

One  new  notation  introduced  in  this  diagram  is  the  striped  rectangle  containing 
“Integer”.  This  notation  is  used  to  distinguish  Ada  built-in  types  such  as  Boolean, 
Integer,  Character,  and  Float  from  types  exported  from  library  components. 

“®The  Replica  operation  makes  a  value  (deep)  copy  of  an  object.  In  RESOLVE,  this  is  a  usually  a 
layered  secondary  operation.  However,  the  Replica  operation  required  for  the  built-in  type  Integer 
is  provided  by  the  special  package  CI_Scalar .Operations. 
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I- isurc  o.'i'?:  A  Detailed  \'i('\v  of  CI_Enhanced_Integer_Queue_l 


The  riuhtinost  arrow  toiieliin,!’  tli(>  ('xt('rior  hoiiiidarv  of  Figtin'  5.23  n'])r('seiits  flit' 
Queue  ty])e  exportc'fl  from  CI_Enhanced_Integer_Queue_l.  The  s])ecifi('{l  Ix'havior  of 
ohjeets  of  tli('  exi)orl(‘d  Queue  typt'  is  tli('  union  of  tlu'  six'cifieatioiis  named  hy  tlu' 
clear  ronnded  boxes  llirongli  which  the  clniin  of  arrows  trttvels.  Tlx'  imphmx'iitations 
liroviding  the  tietnal  beliavior  of  ol)j('(  ts  of  this  ty]x’  are  muix'd  l)y  tlx'  slnxh'd  ix'ct- 
tmeiilar  boxes  (inelndin,i;  th;it  of  the  bnilt-in  ty])e  Integer)  through  which  tlx'  chain 
of  arrows  traw'ls. 

The  Ada  package  s])ecificat ion  whicli  (’iicodes  CI_Enhanced_Integer_Queue_l  is 
shown  in  f  ignre  5.2  1.  I'ignre  5.23  grttpliically  d('i)icts  this  code.  The  concrete  instance 
CI_Scalar_Operations  provides  Swap  ;md  Replica  ])roc('dnr('s  for  .Vda  l)nilt-in  t\  pes 
such  a-'  Integer. 

5.9  RESOLVE/Acla95  Design  Issues 

The  d('velo])mr'nt  of  the  IT\n5  ap]>roach  i)resent(>d  in  this  cha|)ter  involvc'd  ex])lor- 
itig  many  challfuiging  design  issues  and  making  some  com])rotnis(>s.  'Jypc'  extension 
and  hierarchical  librtiry  tmits.  in  ptirt ictilar.  prt'stmtt'd  opporttmitit's  atid  chalh'iiges 
not  addressed  in  t Ix' devf'lo])ment  ofH.\S.3.  W  hile  Ada's  good  support  for  modnl;irit\' 


--  Component:  CI__Enhanced_Integer_Queue_l 

--  Relations :  uses  AT_Queue .  CT__2a,  uses  AT_Queue,With_Reverse.CT_la, 
uses  AT_Queue,With_Replica,CT_la 

Comments :  CI_Scalar_Oparations  provides  Swap  for  built-in  Integer 


--  Global  Context 


with  CI_Scalar_Operations ; 
use  CI_Scalar_Operat ions ; 

with  AT_Queue . CT_2 a ; 

with  AT_Queue . Wi th_Reverse . CT_la ; 

with  AT_Queue . With_Replica . CT_la ; 


package  CI_Enhanced_Integer_Queue_l  is 

--  Local  Instantiations  - 

--  instantiate  AT_Queue  with  Integer 

package  AI_Integer_Queue  is  new 
AT_QueuG ( Item  =>  Integer); 


--  implement  AI_Integer_Queue  with  CT_2a 

package  CI__Integer_Queue  is  new 
AI_Integer_Queue . CT_2a ; 


--  extend  AI_Integer_Queue  with  Reverse 

package  AI_Integer_Queue_With_Reverse  is  new 
AI_Integer_Queue . With_Reverse  ( 

Base_Queue  =>  CI_Integer_Queue .Queue); 


Figure  5.24:  Package  Specification  for  CI_Enhanced_Integer_Queue_l 
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--  ir.plcrr.cr.t  AI_Qucuc_Wi  th_Rcvcrsc  with  CT_la 

package  CI_Intcgcr_Qucuc_With_Rcvcrso  is  new 
-'--_Ir.t:cgor_Quouc_v:it:h_Rovcrsc  .CT_la; 


extend  A'^l_Intcgcr_Qucuc  with  Replica 

package  AI_Ir.t:cgcr_Qucuc_VJi  th_Rcpl ica  is  new 
A:_Int:cgcr_Qucuc  .  v;ith„Rcplica  ( 

3asc_Qucuc  =>  CI_Int:ogcr_Qucuo_Wi  th_Rcvcrsc  .Queue); 


--  irplexent  AI_Qucuc_Wi  th^Rcplica  with  CT_la 

package  C:_Ir.tcger_Queue_Wi th_Rcverse_And_Repl ica  is  new 
AI_Intcgcr_Oucuc_Wi th_Rcpl ica . CT_la ; 


--  Interface 


type  Queue  is  new  CI„Integcr_Qucue_Wi th_Revorse_And_Repl ica . Queue 

with  null  record; 


end  C^__:ir-hauccd_int:egcr_Qucuc_l  ; 


Fimirf'  u/iu:  S])f'eific;it ion  for  CI_Enhanced_Integer_Queue_l  (C'ontiiiiiod) 


rind  ui’iH'i  ifii \  makes  it  ])ossil)l(‘  toa])])ly  iinu'li  of  tlu'  Rk.S()L\  E  discapliiu' using  Ada. 
EES()L\  \\  and  Ada  art’  far  from  Ix’ing  a  ptadc'cl  mateli.  In  this  st'ction.  wv  discuss 
some  of  the  major  issues  farced  in  tlu'  d('V(dopm('nt  of  RADo. 

5.9.1  Initialization  of  Built-in  Scalars 

DfViliiis  with  Achi  s  hiiilt-in  scalar  types  n'lacscntccl  a  particularly  cliallciip,i!i,c; 
I'liihlcin.  In  Ada.  controlled  lyjx's  iiuiy  Ix'  usc'd  to  ])rovid('  automatic  initialization 
and  finalization  for  all  iisrr-dcfincd  types.  .All  types  derivcxl  frotn  Ada . Finalization's 
Controllad  oi  Liinited_Controlled  ty])es  liav('  autoiuatie  initittlization  tind  finaliza¬ 
tion.  I.xcept  for  access  tape's  which  must  he  initializt'd  to  null.  .Ada's  httilt-in  scalars 


do  not  have  any  automatic  initialization.  In  fact,  built-in  scalars  may  have  initial 
values  that  are  invalid  representations  of  their  type  [Int95b,  §3.3.1(21)]. 

If  Ada  required  a  scalar  to  be  initialized  to  a  valid  value  of  its  type  (not  nec¬ 
essarily  a  particular  fixed  value),  then  for  reasoning  purposes,  the  initial  value  of  a 
scalar  could  be  assumed  to  be  a  specific  undetermined  default  value  and  uninitialized 
scalars  could  have  been  used  in  RA95.  In  this  case,  scalar  types  would  only  lack  a 
potentially  useful  initial  value.  However,  since  uninitialized  scalars  may  have  invalid 
representations,  they  cannot  be  passed  as  arguments  to  operations  since  this  might 
raise  a  Constraint_Error  or  Program_Error  at  runtime  [Int95b,  §13.9.1(9)]. 

In  RESOLVE,  every  variable  is  initialized  to  a  value  of  its  type  at  the  beginning 
of  its  scope  (upon  creation).  A  common  idiom  in  RESOLVE  is  to  swap  the  values  of 
a  local  variable  and  a  consumes  mode  parameter  at  the  beginning  of  an  operation. 
This  swap  is  done  to  obtain  an  initial- valued  object  to  return  for  the  consumes  mode 
parameter  and  to  ensure  finalization  of  the  consumed  object  before  the  return.  Using 
uninitialized  scalars,  such  a  call  to  Swap  could  cause  a  run-time  error. 

Ada’s  Normalize-Scalars  pragma  defined  in  the  Safety  and  Security  Annex  of 
[Int95b]  requires  variables  of  each  scalar  type  to  be  initialized  to  a  specific  documented 
value.  However,  the  implementation  advice  for  this  pragma  recommends  that  the 
initial  value  be  an  invalid  value  for  that  type,  if  possible  [Int95b,  §H.1(1)].  Thus, 
Normalize-Scalars,  which  is  intended  to  make  it  easier  to  detect  use  of  scalars  before 
programmer  initialization,  advises  that  compilers  do  exactly  the  opposite  of  what 
RA95  needs  upon  initialization.  Therefore,  Normalize_Scalars,  w'hen  implemented 
faithfully,  is  of  no  use  for  implementing  RA95. 

One  approach  to  built-in  types,  adopted  by  RESOLVE,  is  to  eliminate  built-in 
types  from  the  language  [Har90,  §3.3.2].  Unfortunately,  this  solution  cannot  be  used 
with  Ada  or  C-I--I-  which  rely  heavily  on  built-in  types,  and  is  impractical  when  the 
syntactic  sugar  that  comes  with  built-in  types  cannot  be  duplicated  for  user-defined 
replacements. 

The  solution  we  chose  was  to  alter  compiler  source  code  so  that  scalars  are  au¬ 
tomatically  initialized.  We  modified  the  implementation  of  the  Normalize_Scalars 
pragma  in  the  publicly  available  GNAT  source  code.  The  modified  compiler  satisfies 
the  requirements  of  the  language  definition,  although  it  is  in  direct  opposition  to  the 
implementation  advice  provided.  This  is  not  an  ideal  approach  due  to  portability 
issues,  but  it  does  not  result  in  the  awkward  coding  style  and  inefficiencies  of  the 
alternatives. 


5.9.2  Limitations  of  Child  Units 

The  use  of  generic  child  units  for  encoding  the  implements  and  extends  rela¬ 
tionships  has  seA^eral  advantages.  As  discussed  in  Section  5.4,  concrete  component  has 
direct  visibility  of  any  specification  parameters  and  other  elements  within  its  generic 
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pnrcMit  unit.  Also,  tlic' child  unit  inunin^u^  coin'c'nt ion  is  convc'iiit'nt .  Using  child  units. 
ho\v('V('r,  docs  i)rcscnt  soni(’  liniitat ions.  Ada  docs  not  allow  th('  instantiation  of  a 
|)ar(‘nt  unit  within  a  child  unit  of  that  ])arcnt,  Tlu'  i)ar(’nt  unit  is  within  tin'  s(‘o]m'  of 
the  child  unit .  thus  inaking  such  an  instantiation  r('cui-siv(\  and  Ada  docs  not  sup])ort 
r('cur>i\'('  instantiation  of  gfUKuic  units.  As  a  result,  a  (‘onenMt'  coin])on(uit  c^annot  cre- 
atf‘  aiifl  usr‘  an  instantiation  of  a  sibling  unit  for  which  the  panuit  unit  has  diffenutt 
spccificat ioti  j)arani('tf'rs.  This  pn'cliuh's  sp(H*iali/at ion  coniponents  that  fix  one  or 
inor('  s])f'cification  paranuuers  from  Ix'ing  (‘hild  units  of  th('  k(U'nel  concept  that  tlu'v 
spr'ciali/(\  \\  hih'  ])artial  instantiation  of  only  iniplcmuuitation  ])aranieters  works  in 
soiiH^  cases,  thf'rt'  an'  subtle'  situations  wlu'n'  mutual  recursion  of  instantiated  units 
can  pn'Vf'tit  an  instantiation  that  is  l(\gal  in  RIASOIA'E. 

A^  an  example'  of  this  pre)bl('m.  ('onside'r  tlu'  local  instantiation  of  CI_One_Way_List 
shown  in  Figiin'  o.l?  on  |)ag('  Idl.  If  the  imi)lementation,  AI_One_Way_List . CT_la  in 
thi^  casf\  we're'  built  using  an  im])le'me'ntatie)n  of  AT_Queue.  tlu'n  the'  instantiation  of 
CI_One_V/ay_List  we)uld  ine*lude'  an  instantiation  of  AT_Queue.  The're^fore',  anv  instan¬ 
tiation  e)f  AT_Queue .  CT_2  would  ine-lude'  an  instantiatie)n  e)f  AT_Queue  whi(‘li  is  not 
alhA\e'el  in  Aela.  In  ge'iie'ral,  the'  re'cairsie)!!  among  two  or  more'  components  (T)uld  be 
hielde'ii  in  de'e'plv  laye're'd  im])le'nient atie)ns.  While'  case's  of  mutual  recursion  su(‘li  as 
thi>  might  not  arise'  fre'ejiie'iit ly.  ge'iH'ral  solutions  fe)r  ave)iding  it  tend  to  be'  tex^  e)verly 
const  rainiim. 


5.10  Chapter  Summary 

In  this  e*ha])te'r  we'  de'nie)nstrate'el  he)w  the'  b('ha\de)ral  re'lat ie)nships  de'fine'd  in  Cha])- 
te'r  .3  cati  be'  encexle'el  in  Aela.  In  de)ing  se).  we'  alse)  pre'sente'd  most  as])('e1s  of  the  RE- 
S(  )IA  E/.VelaD.)  elise*i])Iine*  fe)!' se)ft \\'ai'e' (‘e)mpe)ne'nt  ('iigine'e'ring.  Aela  is  be'tte'r  e'ejuip])e'd 
to  ene'oeie  the'se'  re'lat ie)nships  tlnm  me)st  pre)gTa mining  language's  eliu'  te)  its  stre)iig  sup- 
pe)rt  foi'  me)flularity  anel  ])aranietrie‘  pe)lyme)rphism.  Ilowe've'r.  lu'w  language  me'cha- 
ni^ms.  siieii  as  ty])e  e'xte'nsie)n  (inhe'ritane-e')  anel  hierarchie*al  librarie's  (ceiinjionent 
e'Xt e'lision ) ,  aelde'd  tee  Aela  in  lOD.).  luu'e'  alse)  pren'e'ii  use'ful  feir  enceeding  comjieinent 
re’lat  ionshijes. 

As  with  language's  is  the'  Moelule'-2  family,  but  unlike'  meest  eether  language's.  Ada 
e'om])onents  (pae-kage's)  must  e'Xplieutly  name'  any  ceempone'iits  u])on  whie‘h  the'v  de'- 
pe'iiel.  Ada  s  with  e*e)nte'xt  (‘lause’  thus  se'rve's  we'll  foi*  encoeling  the'  uses  relatieinship. 
We'  use'  Aela  s  abstract  tyjee's  anel  abstraeU  eiperatieins  to  e'ne*e)ele'  the  strue-tiiral  as- 
pe'cts  e)f  an  abstiaeU  e’e)m])e)ne'nt .  Be'lia\‘ie)i'al  s])('e*ifie*atioiis  are  re'corele'el  in  sti’ueU  iire'd 
e'omine’nts  using  the’  Rh..SOIA  s])ee*ifie-at ieeii  neitatieen.  Aela's  type  e'xte'nsieen  (single' 
inhe'iit ane‘(’)  anel  child  unit  me'chanisms  are'  use'el  in  conjunctiein  te)  e'ne-e)de'  be)th  the' 
implements  anel  extends  re'lat ie)nships.  We  use'  mixiii  inlu'ritanex'  te)  ene-oele'  multi¬ 
ple'  fle'pe'iiele'neie's  with  e'xte'usie)!)  iinple'ine'iit ations.  Tlie'  needs  re'lat ionshi])  is  encode'el 


in  Ada  using  a  pair  of  related  generic  formal  parameters  and  a  with  clause  encod¬ 
ing  the  uses  relationship  between  the  concrete  template  that  needs  the  abstract 
component. 

In  Section  5.7,  we  discussed  the  specializes  and  checks  relationships  which  are 
somewhat  unique  to  the  RESOLVE  approach.  These  are  both  special  cases  of  the 
implements  relationship.  We  concluded  this  chapter  with  a  discussion  of  several 
RA95  design  issues.  Even  with  its  extensive  assortment  of  language  mechanisms,  Ada 
does  not  provide  an  ideal  level  of  support  for  the  RESOLVE  approach  to  component- 
based  software  engineering. 
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CHAPTER  6 


CONCLUSION 


In  this  chapter  we  summarize  the  research  conducted  for  this  dissertation  and 
present  conclusions  drawn  from  it.  We  then  present  the  contributions  of  this  research 
to  the  field  of  computer  science,  and  conclude  with  a  discussion  of  areas  for  future 
work. 


6.1  Summary  and  Conclusions 

This  dissertation  defends  the  thesis  that  component-level  maintenance  of  software 
systems  may  be  based  on  a  small  set  of  behavioral  and  dependency  relationships 
between  software  components,  and  that  these  relationships  can  be  encoded  with  the 
language  mechanisms  provided  by  modern  programming  languages,  although  not  as 
easily  as  should  be  possible.  Chapters  2  and  3  address  the  first  part  of  this  thesis. 
Chapters  4  and  5  address  the  second  part. 

In  Chapter  2,  we  developed  a  relatively  simple  set  theoretic  model  of  behavioral 
relationships  between  software  components.  The  model  does  not  depend  on  a  spe¬ 
cific  language  sjmtax  or  semantics.  Instead,  it  assumes  that  a  language  syntax  and 
semantics  are  defined.  Then  the  model  defines  behavioral  relationships  between  com¬ 
ponents,  which  may  be  specifications  or  implementations,  either  of  which  may  be 
parameterized  or  not.  The  relations  defined,  imps,  exts,  uses,  and  needs,  are  used 
to  model  behaAUoral  conformance  and  dependencies  between  components. 

Chapter  3  explains  how  the  relations  defined  in  Chapter  2  may  be  used  for 
component-level  maintenance  of  software  systems.  In  order  to  remove  one  component 
from  a  system  and  replace  it  with  a  behavior  ally  compatible  component,  components 
must  be  designed  with  two  relationships  clearly  documented.  First,  each  component 
in  the  system  that  uses  the  component  to  be  replaced  must  state  its  behavioral 
requirement  for  a  suitable  implementation.  This  is  the  role  played  by  the  needs  re¬ 
lationship.  Second,  each  component  should  state  its  behavioral  conformance  to  one 
or  more  specifications.  This  is  the  role  played  by  the  implements  relationship.  The 
extends  relationship  is  important  for  adding  new  functionality  to  components,  while 
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mnintniiiinu  ('oiifoininiicc  to  existing;  s])r<  ifi(';itioiis.  and  thus  iiiiiiinii/ing  the  ofiects 
of  (iiaiiues, 

Moflf'rii  i)ro,u:raintnin<;  lan,t;ita,u;cs  do  not  |)r()vid('  id(>al  sui)])()rl  for  ('iicoding  the  be¬ 
havioral  relationships  we  (hdine.  C  hapter  1  (h’serilx's  a  vjiriety  of  a])proaeh('s  to  tisinu; 
the  inechatiisins  of  niodc'rn  proy.ratntninti,  lan"iia,ti,('s  to  ('iieode  th('S('  r('lationshi])s.  Iti 
Chapter  b.  w('  ch'inotistrate  si)eeifically  how  the  relationshi])s  defined  in  Chapter  3 
can  be  eneod('(l  in  Ada.  C  ha])ter  a  also  prc'sents  the  HI-SC)IA  E/AdaO-')  disei])line  for 
software'  eotn])otient  etittitieeritiy;. 


6.2  Contributions 

I  he  foens  of  this  research  has  bee’ti  to  define  ;i  s('t  of  Ix'havioral  re'latiotiships 
between  software  eonipoiH'iits  and  to  invest i,!i;ate  ways  in  which  tlx'se'  re'lationship 
niav  Ix'  encoded  nsiny,  niodern  prograinining  langtiagc's.  Tlx-  priinary  contributions 
of  thi'  research  to  the  field  of  coniptiter  seietiee  art'  as  follows: 


A  Model  of  Software  Component  Relationships 

The  nxxlel  of  software  eoniitoiK'nt  r('Iationshii)s  (h'veloped  during  this  research 
aiifl  defiiif'd  in  Sections  2. 2-2. 4  provide-s  a  single  formal  franu'work  caj)turitig  tlx'  se¬ 
mantics  of  iv'lat ionshi])s  Ix'tween  ('xt'cntabh'  program  comjxtnents.  sjx'cifications.  and 
templates.  The  chief  levt'iagt'  gained  by  using  tlx'  nxxlel  is  that  the  mmniufi  speci¬ 
fications  aiifl  tetn])lates  nniy  be  understood  in  terms  of  the  semtititics  of  oiterational 
ix-omam  compotif'iits  ratlx'r  thati  jitst  as  .syntactic  tratisformatiotis  of  strings  of  char- 
actei>.  The  model  is  inde])endent  of  the  language  list'd  to  encode  cotn]xttx'nts  and 
the  fortnalisms  used  to  \'erify  the  corrt'ct ix'ss  of  ati  implementation. 


Definition  of  Relationships  Supporting  Component-Level  Maintenance 

1  he  com])oix'nt  relat  ionshi])s  dt'fiix'd  in  Chapter  3  .ser\('  as  a  basis  for  component- 
le^■el  maintetitmct'  of  software'  Ix'canst'  tlx'y  allow  (h'pt'txh'ncies  Ix'twt't'ii  components 
to  be  staK'fl  in  tt'rms  of  behavioral  rt'tinirt'iix'tits.  ratlx'r  than  purt'ly  syntactic  rt'cinin'- 
ments.  This  allows  imph'nx'ntation  compoix'tits  to  Ix'  (h'couph'd  from  t'acli  otlx'r  prior 
to  system  intf'gration  and  promott's  a  ch'ar  distinction  Ix'twt't'ii  (h'sign  d('])end('ticies 
and  inti'gration  d('])('nd('nci('s.  'ihe  ('xamph's  ])r('S('nt t'd  in  Chajitt'rs  3  and  b  (h'timti- 
strate  how  these  rt'lat ionships  may  Ix'  list'd  in  |)ractict'  tt)  support  tlx'  wt'll-t'stablislx'd 
sofiwart'  t'ligini'ering  jirinciples  tif  nmthilarity.  informatitxi  hitling.  polytneirphism.  anti 
t'xtentlibiliiv. 


The  RESOLVE/ Ada95  Discipline 

The  RA95  discipline  for  component-based  software  development,  presented  in 
Chapter  5,  was  developed  as  part  of  the  research  effort  documented  in  this  disserta¬ 
tion.  RA95  provides  a  way  for  software  engineers  to  apply  the  principles  of  RESOLVE 
in  a  well-supported  and  widely  available  programming  language  suitable  for  develop¬ 
ment  of  large  complex  software  systems.  In  addition  to  providing  a  concrete  example 
of  how  component  relationships  may  be  encoded,  RA95  illustrates  new  and  inno¬ 
vate  uses  of  Ada’s  unique  language  mechanisms.  In  particular,  RA95  demonstrates 
how  parametric  polymorphism  (in  the  form  of  Ada  generics)  and  subtype  polymor¬ 
phism  (in  the  form  of  Ada  type  extension)  may  be  used  in  combination  to  develop 
well-encapsulated  extendible  template  components.  Also,  the  component  instantia¬ 
tion  diagrams  presented  in  Chapter  5  should  serve  as  a  useful  aid  for  explaining  and 
generating  often  complex  compositions  of  Ada  components. 

6.3  Future  Research 

Future  work  in  the  area  of  software  component  relationships  might  progress  in 
several  directions.  The  following  sections  each  discuss  a  potential  area  for  further 
research. 

Applying  the  Model  to  Physical  Components 

An  interesting  aspect  of  the  component  relationship  model  presented  in  Chapter  2 
is  that  appears  general  enough  to  apply  to  physical  components  as  well  as  software 
components.  While  physical  systems  are  not  symbolic,  they  do  exhibit  behaviors 
and  their  design  documents  are  symbolic.  Figure  2.1  on  page  15  suggests  how  the 
implements  and  needs  relationships  might  be  applied  in  physical  systems.  Using  a 
single  behavioral  framework  to  describe  both  software  and  hardware  artifacts  might 
prove  useful  in  dealing  with  formal  models  of  embedded  systems,  where  the  physical 
system  being  controlled  and  the  embedded  software  must  be  analyzed  and  designed 
together.  Such  a  framework  might  also  lead  to  a  better  understand  the  similarities 
between  well-engineered  physical  systems  and  well-engineered  software  systems. 

Extending  The  Model 

One  of  the  strengths  of  the  component  relationship  model  presented  in  Chapter  2 
is  its  relative  simplicity.  The  model  is  expressive  enough  to  capture  the  second-order 
nature  of  templates  which  matches  the  full  capability  of  templates  in  programming 
languages  such  as  Ada  and  C-1— P.  Sitaraman  has  pointed  out,  however,  a  practical 
need  for  allowing  (uninstantiated)  template  components  as  parameters  to  template 
components  [Sit92].  Such  “higher  order”  component  compositions  are  expressible 
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within  iIk’  AC’ 1 1  inodf'l.  hut  not  within  tlu^  inoch'I  pi'osontc'cl  in  C’ha])t('r  2.  Extcnirliiif!; 
tlu'  ('()in])onrnt  rrlationship  niofhd  to  allow  (‘xj^rnssion  of  highur  ordor  coinpositions 
would  h(‘  a  worthy  avcniiu'  of  fiirthnr  rnscxirch. 

Component  Relationship-Based  Tools 

IIh'  (‘oinpoiunit  rrlationshi])s  piTS(nited  in  this  dissf'rtatioji  should  l)r  very  useful 
for  oryani/iny  anrl  usiny  soft wan^  (‘oniponent  lihraric's.  C’urrent  inudyation  tools  sueh 
as  “elass  browsers'*,  are  l)as(Hl  on  dircx’t  eoupling  relationshi])s.  iiK'ludiny  inheritance 
links.  A  library  lunayation  tool  basfxl  on  Ixdiavioral  (sfunant ically  significant)  rela- 
tionshij)s  should  bf'  iiioix'  us('fub  espf’cially  for  int(\gration  of  ('xist iiig  c()inj)onents  and 
coiu]>onentdf'\-f'l  systfMu  inaint (nianc(\  Dt'signing  and  iin])l(nnenting  a  tool  based  on 
tlH‘  n'lationshi])S  prf\sfnit(*d  in  C’hapt('r  3  would  lik('ly  b('  a  us('ful  diredion  for  furthcn' 
work. 

Another  int('r(\st ing  (dlort  would  b('  th('  (h'sigii  and  d('velo])inent  of  a  (‘oinponent 
coinpf)sition  tool  that  gcnieratc's  instantiation  codcn  such  at  that  shown  in  Figur(\s  .*3/24 
and  ■).2-)  on  payees  140  and  130.  through  graj)hical  nianipulation  of  a  (*orr(\sponding 
coinponf'nt  instantiation  diagram.  su(4i  as  that  shown  in  Figure'  3.23  on  page'  148. 

Further  Developing  RESOLVE/ Ada95 

I  Ina-f'  are'  a  iiiiinber  of  ave'inu's  for  furtlu'r  developme'ut  of  RAf)3.  Initial  ('fforts 
to  iiK4iule*  run-tinu'  se‘ledal)Ie'  (dynamically  bound)  {‘om])on('nts  in  RA93  (iiK4uding 
f'fforts  by  Palis  fPalO.)])  we're'  ne)t  fully  sue*cessful  due'  the'  ce)mple'xity  of  ce)de'  re'cjuire'd 
anrl  probh'ins  with  e'arly  Adaf).)  compih'rs.  With  im])roved  Adan3  ce)mpile'rs  and 
e'xi)e'rie'iK-f'  with  i)aralle'l  e'florts  in  RI'.SOIA’F/C’-h-h.  it  may  be'  worth  re-inve'stigating 
t his  nrc'a  of  re'sear(4i. 

I)('s])it('  Ada's  mismate'lu's  with  the'  RFSOIA'F  language,  ('iisuring  that  RA03  code' 
is  l(‘u;al  (portable*)  Aela  ce)el('  thus  far  has  be'cn  a  priority  in  the'  de'\'elopment  of  RA93. 
Xe‘\7'rt he'le‘ss.  the*  ])ublic  availability  of  we'll-docume'uteel  soiirea'  ce)d('  for  the'  GNAT 
e‘om])ile‘r  ofh'i's  t he*  opport  unity  te)  moelify  the'  rF\93  se)ure“e'  language'  so  that  it  is  more 
suitable*  for  RP.SOIA  P.-style*  e*om])e)ne'nts.  As  discussefl  in  Se'ction  3.9.1.  the  GXAT 
compile-r  was  morlifie'd  to  atit e)mat  ie’ally  initiali/e'  scalars.  Modifying  GXAT  b\-  adding 
Swap  (pe'rha])s  as  infix  “:  =  :")  as  an  intrinsie’  oi)('ratie)n  for  built-in  scalars,  adeling  it 
to  Ada. Finalization,  and  allowing  “in  e)Ut  parame'te'rs  for  fune*tie)ns.  woulel  make' 
R.\9.)  sonre'e*  e’ode*  much  simph'r  anel  the'  ge'ue'rate'd  e)bje'e‘t  coeh'  me)re'  e'ffieaent. 
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